From cizbasa at info.uvt.ro Wed Nov 2 13:10:57 2005 From: cizbasa at info.uvt.ro (Cornel Izbasa) Date: Wed, 2 Nov 2005 04:10:57 +0200 (EET) Subject: No subject In-Reply-To: References: Message-ID: Hello, I've noticed that ssh always opens /etc/passwd on my Linux box before parsing command line options, and so the file is opened even if the user is afterward presented with the usage and the program ends. So, this snippet in OpenSSH-4.2p1, ssh.c: 219 /* Get user data. */ pw = getpwuid(original_real_uid); if (!pw) { logit("You don't exist, go away!"); exit(1); } /* Take a copy of the returned structure. */ pw = pwcopy(pw); should probably be moved after options scanning, for example at ssh: 515, after: /* Check that we got a host name. */ if (!host) usage(); I tested this and nothing seems to be broken by it. I can submit a patch if it is wanted. Cornel From alon.barlev at gmail.com Wed Nov 2 07:12:35 2005 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Tue, 01 Nov 2005 22:12:35 +0200 Subject: PKCS#11 support for openssh Message-ID: <4367CC33.9020006@gmail.com> Hello OpenSSH developers, A week ago I've posted a patch that enables openssh to work with PKCS#11 tokens. I didn't receive any comments regarding the patch or reply to my questions. In current software world, providing a security product that does not support standard interface for external cryptographic hardware makes the product obsolete. Please comment my patch, so I can know how to proceed. Best Regards, Alon Bar-Lev. From djm at mindrot.org Wed Nov 2 18:34:20 2005 From: djm at mindrot.org (Damien Miller) Date: Wed, 2 Nov 2005 18:34:20 +1100 (EST) Subject: PKCS#11 support for openssh In-Reply-To: <4367CC33.9020006@gmail.com> References: <4367CC33.9020006@gmail.com> Message-ID: On Tue, 1 Nov 2005, Alon Bar-Lev wrote: > Hello OpenSSH developers, > > A week ago I've posted a patch that enables openssh to work with PKCS#11 > tokens. > > I didn't receive any comments regarding the patch or reply to my questions. > > In current software world, providing a security product that does not support > standard interface for external cryptographic hardware makes the product > obsolete. > > Please comment my patch, so I can know how to proceed. I am busy at the moment, hopefully I will have time to look at it properly next week. Looking at it briefly, I was concerned about the assumption of X.509 support - we have no intention of including x.509 at present. -d From djm at mindrot.org Wed Nov 2 18:36:38 2005 From: djm at mindrot.org (Damien Miller) Date: Wed, 2 Nov 2005 18:36:38 +1100 (EST) Subject: your mail In-Reply-To: References: Message-ID: Why change this? On Wed, 2 Nov 2005, Cornel Izbasa wrote: > Hello, > > I've noticed that ssh always opens /etc/passwd > on my Linux box before parsing command line options, and so the file is > opened even if the user is afterward presented with the usage and the > program ends. > So, this snippet in OpenSSH-4.2p1, > ssh.c: 219 > /* Get user data. */ > pw = getpwuid(original_real_uid); > if (!pw) { > logit("You don't exist, go away!"); > exit(1); > } > /* Take a copy of the returned structure. */ > pw = pwcopy(pw); > > should probably be moved after options scanning, for example at > ssh: 515, after: > /* Check that we got a host name. */ > if (!host) > usage(); > > I tested this and nothing seems to be broken by it. I can submit a patch > if it is wanted. > > Cornel > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From cizbasa at info.uvt.ro Wed Nov 2 18:54:53 2005 From: cizbasa at info.uvt.ro (Cornel Izbasa) Date: Wed, 2 Nov 2005 09:54:53 +0200 (EET) Subject: your mail In-Reply-To: References: Message-ID: > Why change this? For optimization and clarity, since read_data_file() is done uselessly in some cases because the program just prints out usage and ends. -- current read_data_file() if(!sanity_check_that_doesn_t_need_the_data()) exit() use_data() as opposed to ++ proposed if(!sanity_check()) exit() read_data_file() use_data() > > On Wed, 2 Nov 2005, Cornel Izbasa wrote: > > > Hello, > > > > I've noticed that ssh always opens /etc/passwd > > on my Linux box before parsing command line options, and so the file is > > opened even if the user is afterward presented with the usage and the > > program ends. > > So, this snippet in OpenSSH-4.2p1, > > ssh.c: 219 > > /* Get user data. */ > > pw = getpwuid(original_real_uid); > > if (!pw) { > > logit("You don't exist, go away!"); > > exit(1); > > } > > /* Take a copy of the returned structure. */ > > pw = pwcopy(pw); > > > > should probably be moved after options scanning, for example at > > ssh: 515, after: > > /* Check that we got a host name. */ > > if (!host) > > usage(); > > > > I tested this and nothing seems to be broken by it. I can submit a patch > > if it is wanted. > > > > Cornel > > > > _______________________________________________ > > openssh-unix-dev mailing list > > openssh-unix-dev at mindrot.org > > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > > From martin at oneiros.de Thu Nov 3 02:38:28 2005 From: martin at oneiros.de (Martin =?iso-8859-1?Q?Schr=F6der?=) Date: Wed, 2 Nov 2005 16:38:28 +0100 Subject: sftp/scp hangs at connection, but ssh is OK In-Reply-To: <20051030154611.GB17112@lucien.oneiros.kn-bremen.de> References: <20051030154611.GB17112@lucien.oneiros.kn-bremen.de> Message-ID: <20051102153828.GD16614@lucien.oneiros.kn-bremen.de> On 2005-10-30 16:46:11 +0100, Martin Schr?der wrote: > I've read the FAQ and googled, but I'm still stymied: > ssh localhost works, but scp and sftp both hang. > > ssh is OpenSSH_4.2p1, OpenSSL 0.9.6c [engine] 21 dec 2001 > > The last lines of an "scp -4 -vvv .bashrc localhost:/tmp/" are: > ---------------------------------- > debug2: mac_init: found hmac-ripemd160 > debug1: kex: server->client aes128-cbc hmac-ripemd160 zlib at openssh.com > debug2: mac_init: found hmac-ripemd160 > debug1: kex: client->server aes128-cbc hmac-ripemd160 zlib at openssh.com > debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<2048<8192) sent > debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP > debug2: dh_gen_key: priv key bits set: 152/320 > debug2: bits set: 1606/3191 > debug1: SSH2_MSG_KEX_DH_GEX_INIT sent > debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY > debug3: check_host_in_hostfile: filename /home/ms/.ssh/known_hosts > debug3: key_read: type mismatch > debug3: check_host_in_hostfile: match line 15 > debug1: Host 'localhost' is known and matches the RSA host key. > debug1: Found key in /home/ms/.ssh/known_hosts:15 > debug2: bits set: 1587/3191 > debug1: ssh_rsa_verify: signature correct > debug2: kex_derive_keys > debug2: set_newkeys: mode 1 > debug1: SSH2_MSG_NEWKEYS sent > debug1: expecting SSH2_MSG_NEWKEYS > debug2: set_newkeys: mode 0 > debug1: SSH2_MSG_NEWKEYS received > debug1: SSH2_MSG_SERVICE_REQUEST sent > debug2: service_accept: ssh-userauth > debug1: SSH2_MSG_SERVICE_ACCEPT received > debug2: key: /home/ms/.ssh/id_dsa (0x809ad70) > debug2: key: /home/ms/.ssh/id_rsa ((nil)) > debug1: Authentications that can continue: publickey,password > debug3: start over, passed a different list publickey,password > debug3: preferred publickey,keyboard-interactive,password > debug3: authmethod_lookup publickey > debug3: remaining preferred: keyboard-interactive,password > debug3: authmethod_is_enabled publickey > debug1: Next authentication method: publickey > debug1: Offering public key: /home/ms/.ssh/id_dsa > debug3: send_pubkey_test > debug2: we sent a publickey packet, wait for reply > debug1: Server accepts key: pkalg ssh-dss blen 432 > debug2: input_userauth_pk_ok: fp 20:e2:42:bb:b2:48:6a:07:db:5c:99:5f:28:1c:17:88 > debug3: sign_and_send_pubkey > debug1: Enabling compression at level 6. > debug1: Authentication succeeded (publickey). > debug2: fd 6 setting O_NONBLOCK > debug2: fd 9 setting O_NONBLOCK > debug1: channel 0: new [client-session] > debug3: ssh_session2_open: channel_new: 0 > debug2: channel 0: send open > debug1: Entering interactive session. > debug2: callback start > debug2: client_session2_setup: id 0 > debug1: Sending command: scp -v -t /tmp/ > debug2: channel 0: request exec confirm 0 > debug2: callback done > debug2: channel 0: open confirm rwindow 0 rmax 32768 > debug2: channel 0: rcvd adjust 131072 > ---------------------------------- > The sshd (running with DEBUG3) produces this: > ---------------------------------- > Oct 30 16:23:13 dream sshd[2122]: Found matching DSA key: 20:e2:42:bb:b2:48:6a:07:db:5c:99:5f:28:1c:17:88 > Oct 30 16:23:13 dream sshd[2122]: debug1: restore_uid: 0/0 > Oct 30 16:23:13 dream sshd[2122]: debug3: mm_answer_keyallowed: key 0x80a3d70 is allowed > Oct 30 16:23:13 dream sshd[2122]: debug3: mm_request_send entering: type 21 > Oct 30 16:23:13 dream sshd[2122]: debug3: mm_request_receive entering > Oct 30 16:23:13 dream sshd[2122]: debug3: monitor_read: checking request 22 > Oct 30 16:23:13 dream sshd[2122]: debug1: ssh_dss_verify: signature correct > Oct 30 16:23:13 dream sshd[2122]: debug3: mm_answer_keyverify: key 0x809ac58 signature verified > Oct 30 16:23:13 dream sshd[2122]: debug3: mm_request_send entering: type 23 > Oct 30 16:23:13 dream sshd[2122]: Accepted publickey for ms from 127.0.0.1 port 32838 ssh2 > Oct 30 16:23:13 dream sshd[2122]: debug1: monitor_child_preauth: ms has been authenticated by privileged process > Oct 30 16:23:13 dream sshd[2122]: debug3: mm_get_keystate: Waiting for new keys > Oct 30 16:23:13 dream sshd[2122]: debug3: mm_request_receive_expect entering: type 24 > Oct 30 16:23:13 dream sshd[2122]: debug3: mm_request_receive entering > Oct 30 16:23:13 dream sshd[2122]: debug3: mm_newkeys_from_blob: 0x809aaa0(140) > Oct 30 16:23:13 dream sshd[2122]: debug2: mac_init: found hmac-ripemd160 > Oct 30 16:23:13 dream sshd[2122]: debug3: mm_get_keystate: Waiting for second key > Oct 30 16:23:13 dream sshd[2122]: debug3: mm_newkeys_from_blob: 0x809aaa0(140) > Oct 30 16:23:13 dream sshd[2122]: debug2: mac_init: found hmac-ripemd160 > Oct 30 16:23:13 dream sshd[2122]: debug3: mm_get_keystate: Getting compression state > Oct 30 16:23:13 dream sshd[2122]: debug3: mm_get_keystate: Getting Network I/O buffers > Oct 30 16:23:13 dream sshd[2122]: debug3: mm_share_sync: Share sync > Oct 30 16:23:13 dream sshd[2122]: debug3: mm_share_sync: Share sync end > Oct 30 16:23:13 dream sshd[2124]: debug1: permanently_set_uid: 500/100 > Oct 30 16:23:13 dream sshd[2124]: debug2: set_newkeys: mode 0 > Oct 30 16:23:13 dream sshd[2124]: debug2: set_newkeys: mode 1 > Oct 30 16:23:13 dream sshd[2124]: debug1: Entering interactive session for SSH2. > Oct 30 16:23:13 dream sshd[2124]: debug2: fd 5 setting O_NONBLOCK > Oct 30 16:23:13 dream sshd[2124]: debug2: fd 6 setting O_NONBLOCK > Oct 30 16:23:13 dream sshd[2124]: debug1: server_init_dispatch_20 > Oct 30 16:23:13 dream sshd[2124]: debug1: server_input_channel_open: ctype session rchan 0 win 131072 max 32768 > Oct 30 16:23:13 dream sshd[2124]: debug1: input_session_request > Oct 30 16:23:13 dream sshd[2124]: debug1: channel 0: new [server-session] > Oct 30 16:23:13 dream sshd[2124]: debug1: session_new: init > Oct 30 16:23:13 dream sshd[2124]: debug1: session_new: session 0 > Oct 30 16:23:13 dream sshd[2124]: debug1: session_open: channel 0 > Oct 30 16:23:13 dream sshd[2124]: debug1: session_open: session 0: link with channel 0 > Oct 30 16:23:13 dream sshd[2124]: debug1: server_input_channel_open: confirm session > Oct 30 16:23:13 dream sshd[2124]: debug1: server_input_channel_req: channel 0 request exec reply 0 > Oct 30 16:23:13 dream sshd[2124]: debug1: session_by_channel: session 0 channel 0 > Oct 30 16:23:13 dream sshd[2124]: debug1: session_input_channel_req: session 0 req exec > Oct 30 16:23:13 dream sshd[2125]: debug3: channel 0: close_fds r -1 w -1 e -1 c -1 > Oct 30 16:23:13 dream sshd[2124]: debug2: fd 8 setting O_NONBLOCK > Oct 30 16:23:13 dream sshd[2124]: debug3: fd 8 is O_NONBLOCK > Oct 30 16:23:13 dream sshd[2124]: debug2: fd 10 setting O_NONBLOCK > Oct 30 16:23:13 dream sshd[2122]: debug2: User child is on pid 2124 > Oct 30 16:23:13 dream sshd[2122]: debug3: mm_request_receive entering > ---------------------------------- > After an Ctrl-C scp exits with > ---------------------------------- > debug1: channel 0: free: client-session, nchannels 1 > debug3: channel 0: status: The following connections are open: > #0 client-session (t4 r0 i0/0 o0/0 fd 6/9 cfd -1) > > debug3: channel 0: close_fds r 6 w 9 e 10 c -1 > debug1: fd 0 clearing O_NONBLOCK > debug1: fd 1 clearing O_NONBLOCK > Killed by signal 2. > ---------------------------------- > And the sshd logs > ---------------------------------- > Oct 30 16:26:09 dream sshd[2124]: Connection closed by 127.0.0.1 > Oct 30 16:26:09 dream sshd[2124]: debug1: channel 0: free: server-session, nchannels 1 > Oct 30 16:26:09 dream sshd[2124]: debug3: channel 0: status: The following connections are open:\r\n #0 server-session (t4 r0 i0/0 o0/0 fd 8/8 cfd -1)\r\n > Oct 30 16:26:09 dream sshd[2124]: debug3: channel 0: close_fds r 8 w 8 e 10 c -1 > Oct 30 16:26:09 dream sshd[2124]: debug1: session_close: session 0 pid 2125 > Oct 30 16:26:09 dream sshd[2124]: debug1: do_cleanup > Oct 30 16:26:09 dream sshd[2124]: Closing connection to 127.0.0.1 > Oct 30 16:26:09 dream sshd[2124]: debug3: mm_request_send entering: type 58 > Oct 30 16:26:09 dream sshd[2122]: debug3: monitor_read: checking request 58 > Oct 30 16:26:09 dream sshd[2122]: debug3: mm_answer_term: tearing down sessions > ---------------------------------- > > The system is a Suse 8.0 (Linux 2.4.18). > > Any idea how to fix this? I tried this on secureshell, but got only garbage or pointers to the FAQ. The FAQ doesn't help: ------------- > echo +`ssh localhost /bin/true`+ ++ ------------- Thanks in advance Martin -- http://www.tm.oneiros.de From alon.barlev at gmail.com Thu Nov 3 06:34:43 2005 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Wed, 02 Nov 2005 21:34:43 +0200 Subject: PKCS#11 support for openssh In-Reply-To: References: <4367CC33.9020006@gmail.com> Message-ID: <436914D3.7030001@gmail.com> Damien Miller wrote: > On Tue, 1 Nov 2005, Alon Bar-Lev wrote: > > I am busy at the moment, hopefully I will have time to look at it > properly next week. Looking at it briefly, I was concerned about the > assumption of X.509 support - we have no intention of including x.509 at > present. > > -d > Thanks! It is good to know that it is somewhere in the queue... I want to explain why I think that X.509 is related to smartcard support... And then I will wait until you have some free time... :) But first, I must say that I don't want to offend anyone... and I am sorry if you already know that, or you think I am talking none-sense. I think your current approach is good for small systems or individuals... But it does not scale. And worse When your standard interface is raw keys on files, you create a false sense of security, since you have a record of a security product... And most people do not know better. Let's say that the user knows that his key was stolen, now he has to create a list of every system that trusted his stolen key and remove the trust. During this phase, the user will most likely forget a few systems, that left vulnerable. Most users will not report that their key was stolen and continue using it... The effort to update a new key in all the systems is too big. So every remote system is left vulnerable. On enterprises, managing raw keys that are distributed all over with people come and go is very difficult, people that leave the enterprise will most likely be able to continue using their keys afterwards for a long period. But there is an advantage... The user can backup his keys... So he can recover his keys from the last backup. So the user never loses his keys and can access his remote systems and modify their trust if he wishes by him-self. Now... when user chooses to use smartcard, I assume he does this because it is more secure... and not because it is a neat device... :) The environment should support this smartcard user. Smartcard keys cannot be backed up... So if the user lose/locks/damaged his card he also loses his keys. Since he does not have his key, he cannot generate a new key and modify the trust of remote systems by him-self... He need to contact the administrator of each remote system and ask him to update the trust, his situation is worse, since he has no way to prove his identity to the administrators, because he lost his keys... Until all the administrators responses the remote systems are vulnerable... But my claim is that there are few systems that the user forgets... Again... If the user uses smartcard because he want to enhance security, the last requirement would be to revoke his last identity from *ALL* remote systems. X.509 provides this service. Lastly, the user will most likely use his smartcard for another purposes... Such as smartcard logon, email signing, SSL authentication... All which are X.509... (Except of gpg... where I had BIG failure...) In order to summarize my argument: 1. X.509 is needed since smartcard user cannot backup his keys, every change of smartcard result in remote system update for *ALL* systems. The management overhead is huge. When using X.509 the user enrolls a new certificate using a different key, and then can access all remote systems without any remote change. 2. X.509 is needed in order to revoke old identities, thus not allowing ghost identities to exist on remote systems. It completes the security requirements when moving from software based storage to smartcards. 3. People who use PKCS#11 most likely uses it in X.509 environment and they wishes to use the same identities also with openssh. And on one sentence... If a user (on large scale) come to a conclusion that he wishes to use secure environment, he most likely use smartcard (PKCS#11) and X.509, drooping each will result in a security weakness. On small scale, most users will not bother to use smartcards... and if they do... you can leave the opensc interface for them... After said that... I can modify my implementation to not using X.509 from openssh point of view, but I will still require X.509 certificate and private key on token... I will also issue a patch for X.509 in order to use the certificate. Regardless, I think that you should reconsider the X.509 support issue. Just to make my-self clearer... I don't think that current implementation of X.509 is complete... There are few issues to solve... But I think that we can all take openssh one step further, and adjust it for todays requirements. Best Regards, Alon Bar-Lev. From Jason.C.Burns at wellsfargo.com Fri Nov 4 10:59:34 2005 From: Jason.C.Burns at wellsfargo.com (Jason.C.Burns at wellsfargo.com) Date: Thu, 3 Nov 2005 17:59:34 -0600 Subject: Question about GSSAPI with OpenSSH 4.2p1 Message-ID: Hey all, perhaps someone might be able to shed a little light on this problem. Nothing I find in books and groups seem to address the problem. I'm trying to set up a series of connections with ssh that authenticate through GSSAPI. However, it seems that the credentials are not getting passed. >From the client.. debug1: Next authentication method: gssapi-with-mic debug2: we sent a gssapi-with-mic packet, wait for reply debug1: Delegating credentials debug1: Delegating credentials debug1: Authentications that can continue: publickey,gssapi-with-mic,password,keyboard-interactive So we can see that the client is configured to send the tickets across... >From the Server... debug1: userauth-request for user / service ssh-connection method gssapi-with-mic debug1: attempt 1 failures 1 debug2: input_userauth_request: try method gssapi-with-mic Postponed gssapi-with-mic for / from xxxx port x ssh2 debug1: Got no client credentials Failed gssapi-with-mic for / from xxxxx port x ssh2 debug1: userauth-request for user / service ssh-connection method keyboard-interactive What does 'Got no client credentials' mean? The client is sending them, so where do they go? Checking the ticket cache on the client... # klist Credentials cache: FILE:/tmp/krb5cc_xxx Principal: /@ Issued Expires Principal Nov 3 17:36:40 Nov 4 03:36:40 krbtgt/domain at realm Nov 3 17:37:52 Nov 4 03:36:40 host/@ So it's even getting the ticket for the machine it is trying to go to using the tgt from the kinit. Any ideas? I'm starting to bang my head against the wall here. Thanks! Jason From evert.vandewaal at imtech.nl Fri Nov 4 21:54:14 2005 From: evert.vandewaal at imtech.nl (Evert van de Waal) Date: Fri, 04 Nov 2005 11:54:14 +0100 Subject: openssh vulnerability WITH TCP DUMP! Message-ID: <436B3DD6.40404@imtech.nl> Hi Guys, My Debian box has been hacked a few days ago using an OpenSSH vulnerability. Subsequently my box was used for sending spam and as a hacking platform (according to my ISP). I was running a fairly recent version of OpenSSH (3.9p1). I reinstalled my box (now with 3.8p1 as supplied by Debian Stable), and started tcpdump to see if I would get lucky. I DID! The aut.log file shows the following: Nov 4 06:25:01 localhost su[5715]: + ??? root:nobody Nov 4 06:25:01 localhost su[5715]: (pam_unix) session opened for user nobody by (uid=0) In the auth.log from my hacked box, I also had these lines. However, I could not correlate them to TCP messages, so they didn't help me. Now, I do have a full tcp dump ;-) In the dump file, I found three simple messages that did the job: First: A SYN request to the ssh port 0000 00 01 80 57 16 3d 00 90 d0 af 86 eb 08 00 45 00 ...W.=.. ......E. 0010 00 30 3c 2d 00 00 74 06 1b fd d2 f0 11 2c 0a 00 .0<-..t. .....,.. 0020 00 82 d6 d3 00 16 7e c1 e4 5f 75 72 0c 80 70 02 ......~. ._ur..p. 0030 ff ff d8 83 00 00 02 04 05 b4 01 01 04 02 ........ ...... Next the reply from my box (SYN ACK): 0000 00 90 d0 af 86 eb 00 01 80 57 16 3d 08 00 45 00 ........ .W.=..E. 0010 00 30 00 00 40 00 40 06 4c 2a 0a 00 00 82 d2 f0 .0.. at .@. L*...... 0020 11 2c 00 16 d6 d3 55 c4 46 41 7e c1 e4 60 70 12 .,....U. FA~..`p. 0030 16 d0 a7 8f 00 00 02 04 05 b4 01 01 04 02 ........ ...... An then the killer. A RST message. The weird ACK (2856040895 according to ethereal) seems to be the culprit: 0000 00 01 80 57 16 3d 00 90 d0 af 86 eb 08 00 45 00 ...W.=.. ......E. 0010 00 28 a3 31 40 00 34 06 b5 00 d2 f0 11 2c 0a 00 .(.1 at .4. .....,.. 0020 00 82 d6 d3 00 16 7e c1 e4 60 00 00 00 00 50 04 ......~. .`....P. 0030 00 00 87 36 00 00 00 00 00 00 00 00 ...6.... .... I don't have a clue how this could cause a session for nobody to be started, I hope this is useful information for you to nail this thing. Or perhaps you have already nailed it, but I didn't find any information on this vulnerability in Google. If you need more information, please let me know. Good luck, Evert From djm at mindrot.org Fri Nov 4 23:17:25 2005 From: djm at mindrot.org (Damien Miller) Date: Fri, 4 Nov 2005 23:17:25 +1100 Subject: openssh vulnerability WITH TCP DUMP! In-Reply-To: <436B3DD6.40404@imtech.nl> References: <436B3DD6.40404@imtech.nl> Message-ID: <20051104231725.04ff7a42.djm@mindrot.org> On Fri, 04 Nov 2005 11:54:14 +0100 Evert van de Waal wrote: > Hi Guys, > > My Debian box has been hacked a few days ago using an OpenSSH > vulnerability. Subsequently my box was used for sending spam and as a > hacking platform (according to my ISP). How do you know it was an OpenSSH vulnerability? You have provided no evidence for this theory, indeed quite the opposite. > The aut.log file shows the following: > Nov 4 06:25:01 localhost su[5715]: + ??? root:nobody > Nov 4 06:25:01 localhost su[5715]: (pam_unix) session opened for user > nobody by > (uid=0) OpenSSH doesn't use uid nobody for anything. So, unless you had a bad password set for your nobody account or you broke your PAM configuration in some way, it probably wasn't OpenSSH that was used to break in to your system. Since you didn't actually post any logs of a break-in (just a later privilege escalation), it is impossible to tell. > In the auth.log from my hacked box, I also had these lines. However, I > could not correlate them to TCP messages, so they didn't help me. Now, I > do have a full tcp dump ;-) What you posted isn't a tcpdump, it is just a hex packet dump. Have you gone out of your way to make it hard to read your packet trace? Even snoop output would have been easier... > In the dump file, I found three simple messages that did the job: > > First: A SYN request to the ssh port > > 0000 00 01 80 57 16 3d 00 90 d0 af 86 eb 08 00 45 00 ...W.=.. ......E. > 0010 00 30 3c 2d 00 00 74 06 1b fd d2 f0 11 2c 0a 00 .0<-..t. .....,.. > 0020 00 82 d6 d3 00 16 7e c1 e4 5f 75 72 0c 80 70 02 ......~. ._ur..p. > 0030 ff ff d8 83 00 00 02 04 05 b4 01 01 04 02 ........ ...... > > Next the reply from my box (SYN ACK): > 0000 00 90 d0 af 86 eb 00 01 80 57 16 3d 08 00 45 00 ........ .W.=..E. > 0010 00 30 00 00 40 00 40 06 4c 2a 0a 00 00 82 d2 f0 .0.. at .@. L*...... > 0020 11 2c 00 16 d6 d3 55 c4 46 41 7e c1 e4 60 70 12 .,....U. FA~..`p. > 0030 16 d0 a7 8f 00 00 02 04 05 b4 01 01 04 02 ........ ...... > > An then the killer. A RST message. The weird ACK (2856040895 according > to ethereal) seems to be the culprit: > 0000 00 01 80 57 16 3d 00 90 d0 af 86 eb 08 00 45 00 ...W.=.. ......E. > 0010 00 28 a3 31 40 00 34 06 b5 00 d2 f0 11 2c 0a 00 .(.1 at .4. .....,.. > 0020 00 82 d6 d3 00 16 7e c1 e4 60 00 00 00 00 50 04 ......~. .`....P. > 0030 00 00 87 36 00 00 00 00 00 00 00 00 ...6.... .... This is not an attack on OpenSSH, it looks like a type of stealth portscan that completes enough of the 3-way handshake to avoid synproxy devices but not enough to activate daemons (thereby leaving spoor in the logs). Someone more interested could probably match it back to one of nmap's modes. BTW ethereal reported the wrong ack sequence number (or you transposed it wrong). -d From dtucker at zip.com.au Fri Nov 4 23:18:59 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 4 Nov 2005 23:18:59 +1100 Subject: openssh vulnerability WITH TCP DUMP! In-Reply-To: <436B3DD6.40404@imtech.nl> References: <436B3DD6.40404@imtech.nl> Message-ID: <20051104121859.GA15798@gate.dodgy.net.au> On Fri, Nov 04, 2005 at 11:54:14AM +0100, Evert van de Waal wrote: > My Debian box has been hacked a few days ago using an OpenSSH > vulnerability. Subsequently my box was used for sending spam and as a > hacking platform (according to my ISP). Why do you think this is an OpenSSH vulnerability? I've only partly decoded the traces but it looks like the ssh connection was being dropped immediately after establishment (such as would be expected if, eg, you are using tcpwrappers). There's no SSH traffic at all, not even the protocol handshake. > I was running a fairly recent version of OpenSSH (3.9p1). I reinstalled > my box (now with 3.8p1 as supplied by Debian Stable), and started > tcpdump to see if I would get lucky. I DID! 3.9p1 built from vanilla source? If so, built with what options? If not, where did you get it? > The aut.log file shows the following: > Nov 4 06:25:01 localhost su[5715]: + ??? root:nobody > Nov 4 06:25:01 localhost su[5715]: (pam_unix) session opened for user > nobody by (uid=0) I don't think that's related. It's a su from root to nobody, and there seems to be some job in the base Debian installation that does that at 06:25 (probably the updatedb job). The sshd syslog entries would be more interesting. I suspect they'll say "refused connection from (some IP)". -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From djm at mindrot.org Fri Nov 4 23:22:54 2005 From: djm at mindrot.org (Damien Miller) Date: Fri, 4 Nov 2005 23:22:54 +1100 Subject: openssh vulnerability WITH TCP DUMP! In-Reply-To: <20051104231725.04ff7a42.djm@mindrot.org> References: <436B3DD6.40404@imtech.nl> <20051104231725.04ff7a42.djm@mindrot.org> Message-ID: <20051104232254.037de86d.djm@mindrot.org> On Fri, 4 Nov 2005 23:17:25 +1100 Damien Miller wrote: > On Fri, 04 Nov 2005 11:54:14 +0100 > Evert van de Waal wrote: > > The aut.log file shows the following: > > Nov 4 06:25:01 localhost su[5715]: + ??? root:nobody > > Nov 4 06:25:01 localhost su[5715]: (pam_unix) session opened for user > > nobody by > > (uid=0) oh, I misread. This is root su'ing to nobody and not the other way round. It is probably not related to malicious activity at all. -d From dtucker at zip.com.au Fri Nov 4 23:51:29 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 4 Nov 2005 23:51:29 +1100 Subject: openssh vulnerability WITH TCP DUMP! In-Reply-To: <20051104121859.GA15798@gate.dodgy.net.au> References: <436B3DD6.40404@imtech.nl> <20051104121859.GA15798@gate.dodgy.net.au> Message-ID: <20051104125128.GA17782@gate.dodgy.net.au> On Fri, Nov 04, 2005 at 11:18:59PM +1100, Darren Tucker wrote: > [...] it looks like the ssh connection was being > dropped immediately after establishment (such as would be expected if, > eg, you are using tcpwrappers). Damien's explanation of this as nmap-like half-open scanning is much better than the one above (for one thing, a connection dropped by tcpwrappers should have the entire 3way tcp handshake). BTW I've decoded all of the first 2 packets: they're pretty vanilla TCP syn/synack packets to/from port 22 with tcp options (MSS=1460 and "SACK permitted"). Nothing of interest. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From Sergio.Gelato at astro.su.se Sat Nov 5 00:34:30 2005 From: Sergio.Gelato at astro.su.se (Sergio Gelato) Date: Fri, 4 Nov 2005 14:34:30 +0100 Subject: Question about GSSAPI with OpenSSH 4.2p1 In-Reply-To: References: Message-ID: <20051104133423.GF5905@hanuman.astro.su.se> * Jason.C.Burns at wellsfargo.com [2005-11-03 17:59:34 -0600]: > Hey all, perhaps someone might be able to shed a little light on this > problem. Nothing I find in books and groups seem to address the > problem. I'm trying to set up a series of connections with ssh that > authenticate through GSSAPI. However, it seems that the credentials are > not getting passed. [...] > debug1: Got no client credentials [...] > What does 'Got no client credentials' mean? The client is sending them, > so where do they go? Are you sure that the client is actually sending them? The credential delegation is buried inside the GSSAPI library, all the OpenSSH code does is to set the "delegate" flag when initialising the security context. If the library is unable to honour that flag, for example because the TGT is not forwardable, then no credential will be forwarded. > Checking the ticket cache on the client... Good idea, but... > > # klist > Credentials cache: FILE:/tmp/krb5cc_xxx > Principal: /@ > > Issued Expires Principal > Nov 3 17:36:40 Nov 4 03:36:40 krbtgt/domain at realm You need to inspect the ticket flags as well. "klist -f" usually shows them (at least in the versions of klist I'm familiar with). > Nov 3 17:37:52 Nov 4 03:36:40 host/@ > > So it's even getting the ticket for the machine it is trying to go to > using the tgt from the kinit. That's not a forwarded ticket, however. The forwarded ticket would not be stored in the client-side credentials cache (it isn't valid for the client's IP address, only for the server's). You can find out whether it is being issued by reading the KDC's logs or by examining the packets exchanged between the GSSAPI library (in the ssh client) and the KDC. > Any ideas? I'm starting to bang my head against the wall here. I'd guess that you forgot to ask for a forwardable TGT at kinit time. There are other possibilities (e.g., a bug in your GSSAPI library; you didn't tell us which version you are using) but hopefully they don't apply to your case. From deengert at anl.gov Sat Nov 5 01:50:45 2005 From: deengert at anl.gov (Douglas E. Engert) Date: Fri, 04 Nov 2005 08:50:45 -0600 Subject: Question about GSSAPI with OpenSSH 4.2p1 In-Reply-To: References: Message-ID: <436B7545.8090804@anl.gov> An Ethereal trace on the client would show the Kerberos activity th the KDC and to the sshd. Jason.C.Burns at wellsfargo.com wrote: > Hey all, perhaps someone might be able to shed a little light on this > problem. Nothing I find in books and groups seem to address the > problem. I'm trying to set up a series of connections with ssh that > authenticate through GSSAPI. However, it seems that the credentials are > not getting passed. > >>From the client.. > > debug1: Next authentication method: gssapi-with-mic > debug2: we sent a gssapi-with-mic packet, wait for reply > debug1: Delegating credentials > debug1: Delegating credentials > debug1: Authentications that can continue: > publickey,gssapi-with-mic,password,keyboard-interactive > > So we can see that the client is configured to send the tickets > across... > >>From the Server... > > debug1: userauth-request for user / service ssh-connection > method gssapi-with-mic > debug1: attempt 1 failures 1 > debug2: input_userauth_request: try method gssapi-with-mic > Postponed gssapi-with-mic for / from xxxx port x ssh2 > debug1: Got no client credentials > Failed gssapi-with-mic for / from xxxxx port x ssh2 > debug1: userauth-request for user / service ssh-connection > method keyboard-interactive > > What does 'Got no client credentials' mean? The client is sending them, > so where do they go? > > Checking the ticket cache on the client... > > # klist > Credentials cache: FILE:/tmp/krb5cc_xxx > Principal: /@ > > Issued Expires Principal > Nov 3 17:36:40 Nov 4 03:36:40 krbtgt/domain at realm > Nov 3 17:37:52 Nov 4 03:36:40 host/@ > > So it's even getting the ticket for the machine it is trying to go to > using the tgt from the kinit. > > Any ideas? I'm starting to bang my head against the wall here. > > Thanks! > > Jason > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From senthilkumar_sen at hotpop.com Sat Nov 5 20:37:50 2005 From: senthilkumar_sen at hotpop.com (Senthil Kumar) Date: Sat, 5 Nov 2005 15:07:50 +0530 Subject: last command shows entries for denied logins Message-ID: <1f2c01c5e1ec$98e98760$220110ac@sekco> Hello All, Im using OpenSSH 4.2p1. Suppose I disable non-root logins to my system through /etc/nologin file, SSH writes an entry for the non-root user in wtmp file. This is because the writing in wtmp file happens in parent process where checking of nologin file happens in the child one. I like to know whether we should put an entry in wtmp file for such denied logins. Any comments will be helpful. Thanks, Senthil Kumar. From dtucker at zip.com.au Tue Nov 8 23:01:28 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 8 Nov 2005 23:01:28 +1100 Subject: last command shows entries for denied logins In-Reply-To: <1f2c01c5e1ec$98e98760$220110ac@sekco> References: <1f2c01c5e1ec$98e98760$220110ac@sekco> Message-ID: <20051108120128.GA21556@gate.dodgy.net.au> On Sat, Nov 05, 2005 at 03:07:50PM +0530, Senthil Kumar wrote: > Im using OpenSSH 4.2p1. Suppose I disable non-root logins to my system > through /etc/nologin file, SSH writes an entry for the non-root user in wtmp > file. This is because the writing in wtmp file happens in parent process > where checking of nologin file happens in the child one. I like to know > whether we should put an entry in wtmp file for such denied logins. >From sshd's perspective, what's happening is that the session is permitted but exits immediately after showing the user the contents of /etc/nologin. The login recording happens when the pty is allocated. Should it do that? Probably not. That behaviour could be changed by checking for /etc/nologin earlier. The trick is you'd have to do it before the pty allocation. Basically, you check nologin and if found, append the content to loginmsg and setting a nologin flag. That flag would need to deny the pty request and cause the shell child to exit immediately after displaying the loginmsg. I did something along those lines at one point to make the BSM audit code able to audit nologin events. I might be able to dig that up. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From shaw at vranix.com Wed Nov 9 12:57:26 2005 From: shaw at vranix.com (Shaw Vrana) Date: Tue, 08 Nov 2005 17:57:26 -0800 Subject: RFC: 64bit compilation warning removal Message-ID: <43715786.6030209@vranix.com> Hello All, I'm getting some compile warnings with openssh on a x86_64 GNU/Linux machine. Specifically, these warnings arise b/c of improper casts in functions taking printf-style formatting arguments. Replacing the format specifications (%u, %d, etc) with the macros in inttypes.h would remove these warnings. This would also require a little bit of work with autoconf as well to ensure portability. The obvious solution is to define the format macros in the case that inttypes.h does not exist. Is this an acceptable practice? and would you accept patches of this kind? Thanks, Shaw From Bob.Barnett at fishersci.com Thu Nov 10 01:48:07 2005 From: Bob.Barnett at fishersci.com (Barnett, Bob) Date: Wed, 9 Nov 2005 09:48:07 -0500 Subject: Solaris 8 password inactivity with openssh Message-ID: <32729C17301C744582A747BD41569C1203BA4B6E@PGHCR-EXMB-VS-1.na.fshrnet.com> All, We have recently updated our password aging to include setting inactivity days. We are running ossh 4.1p1 in a Solaris 8 environment. It appears that ossh isn't picking up on inactivity. Accounts that have been inactive still prompt to change passwords - if you telnet the same servers you get kicked out immediately. On the Solaris 9 servers running SUN's ssh the inactive accounts are being locked. Any ideas? --Bob Barnett From imorgan at nas.nasa.gov Thu Nov 10 03:24:05 2005 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Wed, 9 Nov 2005 08:24:05 -0800 (PST) Subject: Solaris 8 password inactivity with openssh In-Reply-To: <32729C17301C744582A747BD41569C1203BA4B6E@PGHCR-EXMB-VS-1.na.fshrnet.com> from "Barnett, Bob" at Nov 09, 2005 09:48:07 AM Message-ID: <200511091624.jA9GO5pC007303@sun601.nas.nasa.gov> On Wed Nov 9 06:48:07 2005, Barnett, Bob wrote: > > All, > > We have recently updated our password aging to include setting inactivity days. We are running ossh 4.1p1 in a Solaris 8 environment. It appears that ossh isn't picking up on inactivity. Accounts that have been inactive still prompt to change passwords - if you telnet the same servers you get kicked out immediately. On the Solaris 9 servers running SUN's ssh the inactive accounts are being locked. Any ideas? > > As I recall, support for the inactive field in OpenSSH's password aging was deliberately excluded due to inconsistent handling of that field on various OS's. There is a comment in auth-shadow.c indicating that this is a TODO itme. -- Iain Morgan From dtucker at zip.com.au Thu Nov 10 08:37:12 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 10 Nov 2005 08:37:12 +1100 Subject: Solaris 8 password inactivity with openssh In-Reply-To: <200511091624.jA9GO5pC007303@sun601.nas.nasa.gov> References: <32729C17301C744582A747BD41569C1203BA4B6E@PGHCR-EXMB-VS-1.na.fshrnet.com> <200511091624.jA9GO5pC007303@sun601.nas.nasa.gov> Message-ID: <20051109213712.GA12996@gate.dodgy.net.au> On Wed, Nov 09, 2005 at 08:24:05AM -0800, Iain Morgan wrote: > As I recall, support for the inactive field in OpenSSH's password aging was > deliberately excluded due to inconsistent handling of that field on various > OS's. I dug through the archives and found this comment to that effect: http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=101979007119723 but I'm not sure what platforms have which behaviour. > There is a comment in auth-shadow.c indicating that this is a TODO itme. I put that there when I converted the code from being imbedded in auth-passwd.c when I noticed it wasn't handled. The attached patch adds it (against post-4.2 tree but will probably apply to 4.2p1 and 4.1p1). Tested only on Linux. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. -------------- next part -------------- Index: auth-passwd.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/auth-passwd.c,v retrieving revision 1.80 diff -u -p -r1.80 auth-passwd.c --- auth-passwd.c 26 Jul 2005 11:54:12 -0000 1.80 +++ auth-passwd.c 9 Nov 2005 21:18:53 -0000 @@ -74,7 +74,7 @@ auth_password(Authctxt *authctxt, const struct passwd * pw = authctxt->pw; int result, ok = authctxt->valid; #if defined(USE_SHADOW) && defined(HAS_SHADOW_EXPIRE) - static int expire_checked = 0; + static int expire_checked = -1; #endif #ifndef HAVE_CYGWIN @@ -107,11 +107,12 @@ auth_password(Authctxt *authctxt, const return (sshpam_auth_passwd(authctxt, password) && ok); #endif #if defined(USE_SHADOW) && defined(HAS_SHADOW_EXPIRE) - if (!expire_checked) { - expire_checked = 1; - if (auth_shadow_pwexpired(authctxt)) - authctxt->force_pwchange = 1; - } + if (expire_checked == -1) + expire_checked = auth_shadow_pwexpired(authctxt); + if (expire_checked == 1) + authctxt->force_pwchange = 1; + else if (expire_checked == 2) + ok = 0; /* expired too long */ #endif result = sys_auth_passwd(authctxt, password); if (authctxt->force_pwchange) Index: auth-shadow.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/auth-shadow.c,v retrieving revision 1.7 diff -u -p -r1.7 auth-shadow.c --- auth-shadow.c 17 Jul 2005 07:04:47 -0000 1.7 +++ auth-shadow.c 9 Nov 2005 21:15:22 -0000 @@ -78,7 +78,8 @@ auth_shadow_acctexpired(struct spwd *spw /* * Checks password expiry for platforms that use shadow passwd files. - * Returns: 1 = password expired, 0 = password not expired + * Returns: 0 = password not expired, 1 = password expired, + * 2 = password expired too long to be changed. */ int auth_shadow_pwexpired(Authctxt *ctxt) @@ -95,8 +96,9 @@ auth_shadow_pwexpired(Authctxt *ctxt) } today = time(NULL) / DAY; - debug3("%s: today %d sp_lstchg %d sp_max %d", __func__, (int)today, - (int)spw->sp_lstchg, (int)spw->sp_max); + debug3("%s: today %d sp_lstchg %d sp_max %d sp_inact %d", __func__, + (int)today, (int)spw->sp_lstchg, (int)spw->sp_max, + (int)spw->sp_inact); #if defined(__hpux) && !defined(HAVE_SECUREWARE) if (iscomsec()) { @@ -113,7 +115,6 @@ auth_shadow_pwexpired(Authctxt *ctxt) } #endif - /* TODO: check sp_inact */ daysleft = spw->sp_lstchg + spw->sp_max - today; if (disabled) { debug3("password expiration disabled"); @@ -122,6 +123,9 @@ auth_shadow_pwexpired(Authctxt *ctxt) return 1; } else if (spw->sp_max == -1) { debug3("password expiration disabled"); + } else if (spw->sp_inact > 0 && daysleft - spw->sp_inact < 0) { + logit("User %.100s password expired too long", user); + return 2; } else if (daysleft < 0) { logit("User %.100s password has expired (password aged)", user); return 1; From archer at eskimo.com Thu Nov 10 08:40:16 2005 From: archer at eskimo.com (Curt, WE7U) Date: Wed, 9 Nov 2005 13:40:16 -0800 (PST) Subject: Amateur Radio/FCC and the "none" encryption option Message-ID: Is there an easy way to get the "none" option back into OpenSSH? In order to do TCP/IP over amateur radio in the U.S. (and most other countries) we must not use encryption to obscure the meaning of our info, but we are allowed to use authentication to set up the links. This means we need normal authentication but we need the "none" option back in OpenSSH in order to use it across radio links. I found some stuff in the archives that talked about old patches and such, but the developers seem dead-set against adding "none" back in as an option. Is this because nobody could demonstrate a "need", only a "want"? Well, here's a "need"! -- Curt, WE7U. APRS Client Comparisons: http://www.eskimo.com/~archer "Lotto: A tax on people who are bad at math." -- unknown "Windows: Microsoft's tax on computer illiterates." -- WE7U "The world DOES revolve around me: I picked the coordinate system!" From mesposi3 at csc.com Thu Nov 10 08:47:18 2005 From: mesposi3 at csc.com (Mark T Esposito) Date: Wed, 9 Nov 2005 16:47:18 -0500 Subject: OpenSSH 3.4p1 - end of support date ?? Message-ID: For AT&T, looking to find the end of support date for OpenSSH version 3.4 p1. I am not sure if this software is supported but am looking at all software used by AT&T to determine end of support dates needed for a 2006 technology upgrade project. Any information you could supply would be greatly appreciated. Mark Esposito Computer Sciences Corporation ACS Technical Infrastructure (AT&T Account) mesposi3 at csc.com 732.652.6273 ---------------------------------------------------------------------------------------- This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ---------------------------------------------------------------------------------------- From dtucker at zip.com.au Thu Nov 10 09:14:20 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 10 Nov 2005 09:14:20 +1100 Subject: Solaris 8 password inactivity with openssh In-Reply-To: <20051109213712.GA12996@gate.dodgy.net.au> References: <32729C17301C744582A747BD41569C1203BA4B6E@PGHCR-EXMB-VS-1.na.fshrnet.com> <200511091624.jA9GO5pC007303@sun601.nas.nasa.gov> <20051109213712.GA12996@gate.dodgy.net.au> Message-ID: <20051109221420.GA14306@gate.dodgy.net.au> On Thu, Nov 10, 2005 at 08:37:12AM +1100, Darren Tucker wrote: > + } else if (spw->sp_inact > 0 && daysleft - spw->sp_inact < 0) { Thinking about it, this should probably be "spw->sp_inact >= 0". Linux/glibc sets sp_inact to -1 when the field is not populated in /etc/shadow. One wonders what other platforms do... -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Thu Nov 10 09:35:33 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 10 Nov 2005 09:35:33 +1100 Subject: RFC: 64bit compilation warning removal In-Reply-To: <43715786.6030209@vranix.com> References: <43715786.6030209@vranix.com> Message-ID: <20051109223533.GA14930@gate.dodgy.net.au> On Tue, Nov 08, 2005 at 05:57:26PM -0800, Shaw Vrana wrote: > I'm getting some compile warnings with openssh on a x86_64 GNU/Linux > machine. Specifically, these warnings arise b/c of improper casts in > functions taking printf-style formatting arguments. Can you give a couple of examples of the warnings and the changes you're proposing? -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From shaw at vranix.com Thu Nov 10 10:31:12 2005 From: shaw at vranix.com (Shaw Vrana) Date: Wed, 09 Nov 2005 15:31:12 -0800 Subject: RFC: 64bit compilation warning removal In-Reply-To: <20051109223533.GA14930@gate.dodgy.net.au> References: <43715786.6030209@vranix.com> <20051109223533.GA14930@gate.dodgy.net.au> Message-ID: <437286C0.7080409@vranix.com> Hi Darren, Take for example format_rate() in progressmeter.c, specifically this code: before: snprintf(buf, size, "%3lld.%1lld%c%s", (int64_t) (bytes + 5) / 100, (int64_t) (bytes + 5) / 10 % 10, unit[i], i ? "B" : " "); after: snprintf(buf, size, "%3" PRId64 ".%1" PRId64 "%c%s", (int64_t) (bytes + 5) / 100, (int64_t) (bytes + 5) / 10 % 10, unit[i], i ? "B" : " "); PRId64 is defined in inttypes.h as "ld" for 64 bit machines or "lld" for 32bit machines. This allows the code to compile cleanly. I'm also purposing that these macros be added using autoconf if the user does not have inttypes.h. Thanks, Shaw From shaw at vranix.com Thu Nov 10 10:44:06 2005 From: shaw at vranix.com (Shaw Vrana) Date: Wed, 09 Nov 2005 15:44:06 -0800 Subject: RFC: 64bit compilation warning removal In-Reply-To: <437286C0.7080409@vranix.com> References: <43715786.6030209@vranix.com> <20051109223533.GA14930@gate.dodgy.net.au> <437286C0.7080409@vranix.com> Message-ID: <437289C6.6090305@vranix.com> I forgot to attach any warnings to my previous post. Unfortunately, the machine I was using has disappeared and the build stops after one warning. Thus, this is currently the only warning I have, but there are at least a handful more. ../../src/hostfile.c: In function `extract_salt': ../../src/hostfile.c:92: warning: unsigned int format, different type arg (arg 2) Thanks again, Shaw From dtucker at zip.com.au Thu Nov 10 11:21:33 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 10 Nov 2005 11:21:33 +1100 Subject: RFC: 64bit compilation warning removal In-Reply-To: <437289C6.6090305@vranix.com> References: <43715786.6030209@vranix.com> <20051109223533.GA14930@gate.dodgy.net.au> <437286C0.7080409@vranix.com> <437289C6.6090305@vranix.com> Message-ID: <20051110002133.GA17397@gate.dodgy.net.au> On Wed, Nov 09, 2005 at 03:44:06PM -0800, Shaw Vrana wrote: > I forgot to attach any warnings to my previous post. Unfortunately, the > machine I was using has disappeared and the build stops after one > warning. Thus, this is currently the only warning I have, but there are > at least a handful more. > > ../../src/hostfile.c: In function `extract_salt': > ../../src/hostfile.c:92: warning: unsigned int format, different type > arg (arg 2) Well, that one looks like just a bug in the debug() call since "ret" is a signed int (trivial patch below). Those macros make it harder to read, and OpenBSD doesn't have them. Personally, I'd prefer to see the warnings fixed some other way if possible (eg use of appropriate format specs and/or casts where appropriate) and those changes fed back to OpenBSD. Where necessary, those macros could be used (eg your progressmeter example, where the 64 bit type is due to the file size in the sftp protocol being 64 bits on the wire) and carried as a Portable-only change. I'd be interested to hear other opinions on this, though. Index: hostfile.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/hostfile.c,v retrieving revision 1.32 diff -u -p -r1.32 hostfile.c --- hostfile.c 2 Aug 2005 07:07:08 -0000 1.32 +++ hostfile.c 10 Nov 2005 00:15:07 -0000 @@ -88,8 +88,8 @@ extract_salt(const char *s, u_int l, cha return (-1); } if (ret != SHA_DIGEST_LENGTH) { - debug2("extract_salt: expected salt len %u, got %u", - salt_len, ret); + debug2("extract_salt: expected salt len %d, got %d", + SHA_DIGEST_LENGTH, ret); return (-1); } -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From fcusack at fcusack.com Thu Nov 10 11:22:22 2005 From: fcusack at fcusack.com (Frank Cusack) Date: Wed, 09 Nov 2005 16:22:22 -0800 Subject: Solaris 8 password inactivity with openssh In-Reply-To: <32729C17301C744582A747BD41569C1203BA4B6E@PGHCR-EXMB-VS-1.na.fshrnet.com> References: <32729C17301C744582A747BD41569C1203BA4B6E@PGHCR-EXMB-VS-1.na.fshrnet.com> Message-ID: On November 9, 2005 9:48:07 AM -0500 "Barnett, Bob" wrote: > All, > > We have recently updated our password aging to include setting inactivity days. We are running > ossh 4.1p1 in a Solaris 8 environment. It appears that ossh isn't picking up on inactivity. > Accounts that have been inactive still prompt to change passwords - if you telnet the same > servers you get kicked out immediately. On the Solaris 9 servers running SUN's ssh the inactive > accounts are being locked. Any ideas? Try using kbdint auth instead of password. -frank From djm at mindrot.org Thu Nov 10 13:12:00 2005 From: djm at mindrot.org (Damien Miller) Date: Thu, 10 Nov 2005 13:12:00 +1100 (EST) Subject: OpenSSH 3.4p1 - end of support date ?? In-Reply-To: References: Message-ID: We support 3.4 by recommending that users upgrade to a more recent version. OS vendors incorporating OpenSSH typically have support schedules independant of ours. On Wed, 9 Nov 2005, Mark T Esposito wrote: > > > > > For AT&T, looking to find the end of support date for OpenSSH version 3.4 > p1. > I am not sure if this software is supported but am looking at all software > used by AT&T to determine end of support dates needed for a 2006 technology > upgrade project. > > Any information you could supply would be greatly appreciated. > > Mark Esposito > Computer Sciences Corporation > ACS Technical Infrastructure (AT&T Account) > mesposi3 at csc.com > 732.652.6273 > > > ---------------------------------------------------------------------------------------- > > This is a PRIVATE message. If you are not the intended recipient, please > delete without copying and kindly advise us by e-mail of the mistake in > delivery. NOTE: Regardless of content, this e-mail shall not operate to > bind CSC to any order or other contract unless pursuant to explicit written > agreement or government initiative expressly permitting the use of e-mail > for such purpose. > ---------------------------------------------------------------------------------------- > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From shaw at vranix.com Thu Nov 10 12:48:41 2005 From: shaw at vranix.com (Shaw Vrana) Date: Wed, 09 Nov 2005 17:48:41 -0800 Subject: RFC: 64bit compilation warning removal In-Reply-To: <20051110002133.GA17397@gate.dodgy.net.au> References: <43715786.6030209@vranix.com> <20051109223533.GA14930@gate.dodgy.net.au> <437286C0.7080409@vranix.com> <437289C6.6090305@vranix.com> <20051110002133.GA17397@gate.dodgy.net.au> Message-ID: <4372A6F9.5010209@vranix.com> Darren Tucker wrote: > Where necessary, those macros could be used (eg your progressmeter > example, where the 64 bit type is due to the file size in the sftp > protocol being 64 bits on the wire) and carried as a Portable-only > change. I'd be interested to hear other opinions on this, though. They are ugly and I agree that they should only be applied if casting is inappropriate. I have not gone through all of the warnings yet, but hopefully there are not too many of them that cannot be fixed by casting (or bug fixing- good catch, btw). Let's take a closer look after I've got the patches in hand. Thanks for your help, Shaw From dreadi at gmx.net Thu Nov 10 08:21:32 2005 From: dreadi at gmx.net (Jan Bilang) Date: Wed, 9 Nov 2005 22:21:32 +0100 (MET) Subject: KerberosGetAFSToken drives me crazy Message-ID: <4550.1131571292@www47.gmx.net> hi, every time i enable the option "KerberosGetAFSToken yes" on a computer where the afs-client works fine i get a (/var/log/)message(s) like this: "sshd[1136]: rexec line 70: Unsupported option KerberosGetAFSToken". no one get a afs-token via ssh-login. i found this in sshd in suse9.3, suse 10.0 and fedora core 4 but i does not found any informations if this is an error or not. whats wrong here, can anyone help me? regards jan -- Telefonieren Sie schon oder sparen Sie noch? NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie From djm at mindrot.org Thu Nov 10 20:43:01 2005 From: djm at mindrot.org (Damien Miller) Date: Thu, 10 Nov 2005 20:43:01 +1100 Subject: KerberosGetAFSToken drives me crazy In-Reply-To: <4550.1131571292@www47.gmx.net> References: <4550.1131571292@www47.gmx.net> Message-ID: <20051110204301.72d1b9d3.djm@mindrot.org> On Wed, 9 Nov 2005 22:21:32 +0100 (MET) "Jan Bilang" wrote: > hi, > > every time i enable the option "KerberosGetAFSToken yes" on a computer where > the afs-client works fine i get a (/var/log/)message(s) like this: > "sshd[1136]: rexec line 70: Unsupported option KerberosGetAFSToken". no one > get a afs-token via ssh-login. i found this in sshd in suse9.3, suse 10.0 > and fedora core 4 but i does not found any informations if this is an error > or not. whats wrong here, can anyone help me? Your sshd probably has not been compiled with Kerberos support. You didn't bother to quote the sshd version from any of your installs, or whether you compiled from source or just used the system-provided ones. -d From dtucker at zip.com.au Thu Nov 10 21:49:18 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 10 Nov 2005 21:49:18 +1100 Subject: KerberosGetAFSToken drives me crazy In-Reply-To: <4550.1131571292@www47.gmx.net> References: <4550.1131571292@www47.gmx.net> Message-ID: <437325AE.7040506@zip.com.au> Jan Bilang wrote: > every time i enable the option "KerberosGetAFSToken yes" on a computer where > the afs-client works fine i get a (/var/log/)message(s) like this: > "sshd[1136]: rexec line 70: Unsupported option KerberosGetAFSToken". In addtion to requiring Kerberos support, that option only works if your Kerberos implementation has the required AFS bits (k_setpag() and a few other calls) and at the moment, only Heimdal has them. There was talk of adding them as an external library for MIT Kerberos but as far as I know that's never happened. Depending on what your OS vendors have done, it might be possible to configure AFS to work via a PAM module, but that's going to be vendor specific. (Hmm, I see that FC3 has a "krbafs" package which implements some but not all of the functions needed. I don't know if it could be made to work.) -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From banz at umbc.edu Fri Nov 11 04:40:13 2005 From: banz at umbc.edu (Robert Banz) Date: Thu, 10 Nov 2005 12:40:13 -0500 Subject: KerberosGetAFSToken drives me crazy In-Reply-To: <437325AE.7040506@zip.com.au> References: <4550.1131571292@www47.gmx.net> <437325AE.7040506@zip.com.au> Message-ID: <437385FD.6080101@umbc.edu> Darren Tucker wrote: > Jan Bilang wrote: >> every time i enable the option "KerberosGetAFSToken yes" on a computer where >> the afs-client works fine i get a (/var/log/)message(s) like this: >> "sshd[1136]: rexec line 70: Unsupported option KerberosGetAFSToken". > > In addtion to requiring Kerberos support, that option only works if your > Kerberos implementation has the required AFS bits (k_setpag() and a few > other calls) and at the moment, only Heimdal has them. There was talk > of adding them as an external library for MIT Kerberos but as far as I > know that's never happened. > > Depending on what your OS vendors have done, it might be possible to > configure AFS to work via a PAM module, but that's going to be vendor > specific. > > (Hmm, I see that FC3 has a "krbafs" package which implements some but > not all of the functions needed. I don't know if it could be made to > work.) > I've actually gotten things to build with the krbafs package + MIT on multiple architectures (Solaris & OSX.) So, it's all there. -rob From deengert at anl.gov Fri Nov 11 06:46:18 2005 From: deengert at anl.gov (Douglas E. Engert) Date: Thu, 10 Nov 2005 13:46:18 -0600 Subject: KerberosGetAFSToken drives me crazy In-Reply-To: <437385FD.6080101@umbc.edu> References: <4550.1131571292@www47.gmx.net> <437325AE.7040506@zip.com.au> <437385FD.6080101@umbc.edu> Message-ID: <4373A38A.5010207@anl.gov> The other approach is to not have any direct Kerberos or AFS support at all in ssh or sshd. But rather use the GSSAPI and PAM with sshd to get AFS tokens from the forwarded GSSAPI credentials i.e. forwarded K5 tickets. This then avoids problems if the vendor did not compile in the options you wanted or use the Kerberos distributions you wanted. We use the vendor's pam_krb5 if possible for the keyboard interactive, and a pam_afs2 for the kewyboard interactive, and gssapi session. pam_afs2 will get an AFS PAG and call your favoriate aklog to get a token. Drop me a note if you would like more information. Robert Banz wrote: > Darren Tucker wrote: > >>Jan Bilang wrote: >> >>>every time i enable the option "KerberosGetAFSToken yes" on a computer where >>>the afs-client works fine i get a (/var/log/)message(s) like this: >>>"sshd[1136]: rexec line 70: Unsupported option KerberosGetAFSToken". >> >>In addtion to requiring Kerberos support, that option only works if your >>Kerberos implementation has the required AFS bits (k_setpag() and a few >>other calls) and at the moment, only Heimdal has them. There was talk >>of adding them as an external library for MIT Kerberos but as far as I >>know that's never happened. >> >>Depending on what your OS vendors have done, it might be possible to >>configure AFS to work via a PAM module, but that's going to be vendor >>specific. >> >>(Hmm, I see that FC3 has a "krbafs" package which implements some but >>not all of the functions needed. I don't know if it could be made to >>work.) >> > > > I've actually gotten things to build with the krbafs package + MIT on > multiple architectures (Solaris & OSX.) So, it's all there. > > -rob > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From jjb at herfs.net Fri Nov 11 07:10:31 2005 From: jjb at herfs.net (Jaco Breitenbach) Date: Thu, 10 Nov 2005 15:10:31 -0500 (EST) Subject: Encrypted daemon socket communication Message-ID: <27905.168.209.97.42.1131653431.squirrel@168.209.97.42> Hi I have a daemon application that binds and listens on a TCP socket. To add security, I'd like to embed ssh/sshd in my application to handle the encryption and authentication for me. How do you suggest I go about it? Regards, Jaco -- "The future belongs to those who believe in their dreams." -- Nelson Mandela From Jefferson.Ogata at noaa.gov Fri Nov 11 08:01:53 2005 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Thu, 10 Nov 2005 16:01:53 -0500 Subject: Encrypted daemon socket communication In-Reply-To: <27905.168.209.97.42.1131653431.squirrel@168.209.97.42> References: <27905.168.209.97.42.1131653431.squirrel@168.209.97.42> Message-ID: <4373B541.5050106@noaa.gov> On 11/10/2005 03:10 PM, Jaco Breitenbach wrote: > I have a daemon application that binds and listens on a TCP socket. To add > security, I'd like to embed ssh/sshd in my application to handle the > encryption and authentication for me. How do you suggest I go about it? Use stunnel instead. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From djm at mindrot.org Fri Nov 11 12:17:13 2005 From: djm at mindrot.org (Damien Miller) Date: Fri, 11 Nov 2005 12:17:13 +1100 (EST) Subject: Encrypted daemon socket communication In-Reply-To: <27905.168.209.97.42.1131653431.squirrel@168.209.97.42> References: <27905.168.209.97.42.1131653431.squirrel@168.209.97.42> Message-ID: On Thu, 10 Nov 2005, Jaco Breitenbach wrote: > Hi > > I have a daemon application that binds and listens on a TCP socket. To add > security, I'd like to embed ssh/sshd in my application to handle the > encryption and authentication for me. How do you suggest I go about it? OpenSSH doesn't have a library API that allows you to directly link in to an application. On the other hand, it is easy to fork and exec ssh over a set of pipes (or a socketpair) and use it to perform communication on your behalf. Have a look at how the sftp and scp programs in the source distribution do it. If you just want to wrap up an existing TCP-based protocol in a SSH transport, then you might not need to even do this - port forwarding alone may be sufficient. Have a look at the LocalForward, RemoteForward and DynamicForward options in ssh_config(5) (a.k.a -L, -R, -D in ssh(1)). -d From dkg-openssh.com at fifthhorseman.net Fri Nov 11 16:39:51 2005 From: dkg-openssh.com at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 11 Nov 2005 00:39:51 -0500 Subject: Can't get LocalForward to work when using ControlPath Message-ID: <17268.11943.268580.628248@localhost.localdomain> Hello All-- First, thanks for ControlPath/ControlMaster. It's very handy, and ControlMaster=autoask is just what i wanted! I'm having difficulty with a common use case, however. I want to LocalForward on secondary connections using an already-established ControlPath. From what i can tell, the second ssh connection doesn't report any errors, but silently ignores the supplied LocalForward arguments. Is this an expected behavior? from man ssh_config(5), i see that: X11 and ssh-agent(1) forwarding is supported over these multiplexed connections, however the display and agent fowarded will be the one belonging to the master connection i.e. it is not possible to forward multiple displays or agents. But i couldn't find any reference to whether LocalForward (or for that matter, RemoteForward or DynamicForward) should work or not work with multiplexed connections. For my purposes, it would be fine if the master connection opened the new forwarded port, instead of the secondary connection, as long as the secondary one could initiate the forwarding. I'd like for the secondary to be able to tear it down when it's done too, of course, but i could do without that for now. Here's an example of an attempt which appears to fail for me, with a bit of debugging verbosity thrown in: ("5th" is a host with an IMAP server answering on the loopack address) [dkg at squeak ~]$ ssh -Nf -MS ~/.ssh/controls/fubar -L 9999:localhost:143 5th true [dkg at squeak ~]$ ssh -vvv -Nf -S ~/.ssh/controls/fubar -L 8888:localhost:143 5th true OpenSSH_4.2p1 Debian-5.dkg0, OpenSSL 0.9.8a 11 Oct 2005 debug1: Reading configuration data /home/dkg/.ssh/config debug1: Applying options for 5th debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: auto-mux: Trying existing master debug3: ssh_msg_send: type 1 debug3: ssh_msg_recv entering debug3: ssh_msg_send: type 1 debug3: ssh_msg_recv entering debug2: Received exit status from master 0 debug2: Received EOF from master [dkg at squeak ~]$ nmap -p 8888,9999 localhost Starting nmap 3.93 ( http://www.insecure.org/nmap/ ) at 2005-11-11 00:04 EST Interesting ports on localhost.localdomain (127.0.0.1): PORT STATE SERVICE 8888/tcp closed sun-answerbook 9999/tcp open abyss Nmap finished: 1 IP address (1 host up) scanned in 0.141 seconds [dkg at squeak ~]$ As you can see, the initial LocalForward (over localhost port 9999) works just fine, but the second attempted connection (port 8888) never happens and just mysteriously goes away without complaint. Any suggestions or insight you have would be appreciated. As you can see, i'm using a slightly-modified debian openssh 4.2p1-5 (only ./configure flags were changed to include opensc support) on a debian etch/sid system. If this works on other platforms or with other build options, i'd be happy to hear about it. Thanks again for this great tool, --dkg From djm at mindrot.org Fri Nov 11 17:07:03 2005 From: djm at mindrot.org (Damien Miller) Date: Fri, 11 Nov 2005 17:07:03 +1100 (EST) Subject: Can't get LocalForward to work when using ControlPath In-Reply-To: <17268.11943.268580.628248@localhost.localdomain> References: <17268.11943.268580.628248@localhost.localdomain> Message-ID: On Fri, 11 Nov 2005, Daniel Kahn Gillmor wrote: > Hello All-- > > First, thanks for ControlPath/ControlMaster. It's very handy, and > ControlMaster=autoask is just what i wanted! > > I'm having difficulty with a common use case, however. I want to > LocalForward on secondary connections using an already-established > ControlPath. From what i can tell, the second ssh connection doesn't > report any errors, but silently ignores the supplied LocalForward > arguments. Passing additional forwarding requests from multiplexing slaves through to the master has not been implemented yet, but I plan to soon. IIRC someone posted patches to this list or bugzilla, but they needed a little more work. It is uncertain whether this will be in the 4.3 release, more likely to be the 4.4 timeframe (~6 months). There will be patches available on this list or in bugzilla beforehand though if you would like to test. -d From tom at penumbra.be Sat Nov 12 02:33:51 2005 From: tom at penumbra.be (Tom) Date: Fri, 11 Nov 2005 16:33:51 +0100 Subject: login passwd not masked in remote command modus Message-ID: <4374B9DF.8010907@penumbra.be> Hi, I've recently discovered a rather nasty bug. My login password is visible when I use the following command: arioch at server ~ $ ssh arioch at 192.168.0.1 sudo tail -f /var/log/messages; exit Password: ********** (user - masked) Password: my_not-so-secret-anymore_password (root - not masked) -tail output- This has been tested with openssh on OpenBSD, FreeBSD and Gentoo/Linux, all with up-to-date versions of both OpenSSH and Sudo and the output is equally the same. Hoping to be of any service, Tom D.V. -- tom at penumbra.be arioch at penumbra.be From dkg-openssh.com at fifthhorseman.net Sat Nov 12 02:49:51 2005 From: dkg-openssh.com at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 11 Nov 2005 10:49:51 -0500 Subject: login passwd not masked in remote command modus In-Reply-To: <4374B9DF.8010907@penumbra.be> References: <4374B9DF.8010907@penumbra.be> Message-ID: <17268.48543.739610.161439@localhost.localdomain> On November 11, tom at penumbra.be said: > I've recently discovered a rather nasty bug. My login password is > visible when I use the following command: > > arioch at server ~ $ ssh arioch at 192.168.0.1 sudo tail -f /var/log/messages; exit > Password: ********** (user - masked) > Password: my_not-so-secret-anymore_password (root - not masked) This is because when you use ssh with an explicit command (in the example above, your command is sudo), ssh doesn't bother allocating a pseudo-tty for your session, which means that sudo's password-hiding is not done, since it is not running within a terminal, as far as it knows. To force ssh to allocate a pseudo-tty, use -t, as in: ssh -t arioch at 192.168.0.1 sudo tail -f /var/log/messages; exit Use "man ssh" and search for pseudo-tty for more details. Hope this helps, --dkg From archer at eskimo.com Sat Nov 12 04:57:05 2005 From: archer at eskimo.com (Curt, WE7U) Date: Fri, 11 Nov 2005 09:57:05 -0800 (PST) Subject: Amateur Radio/FCC and the "none" encryption option In-Reply-To: References: Message-ID: On Wed, 9 Nov 2005, Curt, WE7U wrote: > Is there an easy way to get the "none" option back into OpenSSH? In > order to do TCP/IP over amateur radio in the U.S. (and most other > countries) we must not use encryption to obscure the meaning of our > info, but we are allowed to use authentication to set up the links. > > This means we need normal authentication but we need the "none" > option back in OpenSSH in order to use it across radio links. I > found some stuff in the archives that talked about old patches and > such, but the developers seem dead-set against adding "none" back in > as an option. Is this because nobody could demonstrate a "need", > only a "want"? Well, here's a "need"! Is there no answer back from the devel. team on this one? We've been struggling to keep this option compiled in and it's been getting harder to find old enough versions that the patches will apply to, and harder to compile such on newer systems. I got one reply off-sig from someone who keeps newer patches available, but why should this be necessary? If there's a demonstrated need from some group of users can't this function be included in the sources as it used to be? It can be made more difficult to accidentally compile in as a default, perhaps a special #define or something that needs to be set or uncommented. Again, this is for use over amateur radio links, and the FCC doesn't allow us to encrypt over radio links. We're allowed to authenticate, but not encrypt the data over a link. Any response? -- Curt, WE7U. APRS Client Comparisons: http://www.eskimo.com/~archer "Lotto: A tax on people who are bad at math." -- unknown "Windows: Microsoft's tax on computer illiterates." -- WE7U "The world DOES revolve around me: I picked the coordinate system!" From dtucker at zip.com.au Sat Nov 12 19:23:55 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 12 Nov 2005 19:23:55 +1100 Subject: KerberosGetAFSToken drives me crazy In-Reply-To: <437385FD.6080101@umbc.edu> References: <4550.1131571292@www47.gmx.net> <437325AE.7040506@zip.com.au> <437385FD.6080101@umbc.edu> Message-ID: <20051112082355.GA17930@gate.dodgy.net.au> On Thu, Nov 10, 2005 at 12:40:13PM -0500, Robert Banz wrote: > I've actually gotten things to build with the krbafs package + MIT on > multiple architectures (Solaris & OSX.) So, it's all there. So it would appear, although it's not called the same thing (thus my quick grep didn't find it) and doesn't seem to take the same arguments. The attached patch makes it build, however as I don't use Kerberos or AFS I can't test it. Can anyone confirm this works? Is this worth adding? -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. -------------- next part -------------- Index: configure.ac =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/configure.ac,v retrieving revision 1.306 diff -u -p -r1.306 configure.ac --- configure.ac 12 Nov 2005 04:20:53 -0000 1.306 +++ configure.ac 12 Nov 2005 08:07:52 -0000 @@ -2907,8 +2907,10 @@ AC_ARG_WITH(kerberos5, AC_CHECK_HEADERS(gssapi_generic.h gssapi/gssapi_generic.h) LIBS="$LIBS $K5LIBS" - AC_SEARCH_LIBS(k_hasafs, kafs, AC_DEFINE(USE_AFS, 1, - [Define this if you want to use libkafs' AFS support])) + AC_SEARCH_LIBS(k_hasafs, kafs krbafs, [AC_DEFINE(USE_AFS, 1, + [Use libkafs or libkrbafs for AFS support])]) + AC_CHECK_HEADERS(kafs.h krbafs.h) + AC_CHECK_FUNCS(krb5_afslog krb_afslog, break) fi ] ) Index: defines.h =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/defines.h,v retrieving revision 1.129 diff -u -p -r1.129 defines.h --- defines.h 9 Oct 2005 01:40:04 -0000 1.129 +++ defines.h 12 Nov 2005 08:17:02 -0000 @@ -576,6 +576,13 @@ struct winsize { # define krb5_get_err_text(context,code) error_message(code) #endif +#if defined(KRB5) && defined(USE_AFS) +# if !defined(HAVE_KRB5_AFSLOG) && defined(HAVE_KRB_AFSLOG) +# define krb5_afslog(a,b,c,d) krb_afslog((c),(d)) +# define krb5_afslog_home(a,b,c,d,e) krb_afslog_home((c),(d),(e)) +# endif +#endif + #if defined(SKEYCHALLENGE_4ARG) # define _compat_skeychallenge(a,b,c,d) skeychallenge(a,b,c,d) #else Index: includes.h =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/includes.h,v retrieving revision 1.77 diff -u -p -r1.77 includes.h --- includes.h 26 Aug 2005 20:15:20 -0000 1.77 +++ includes.h 12 Nov 2005 08:18:51 -0000 @@ -182,8 +182,12 @@ static /**/const char *const rcsid[] = { #endif #if defined(KRB5) && defined(USE_AFS) -# include -# include +# if defined(HAVE_KAFS_H) +# include +# include +# elif defined(HAVE_KRBAFS_H) +# include +# endif #endif #if defined(HAVE_SYS_SYSLOG_H) Index: session.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/session.c,v retrieving revision 1.309 diff -u -p -r1.309 session.c --- session.c 5 Nov 2005 04:15:00 -0000 1.309 +++ session.c 12 Nov 2005 08:19:14 -0000 @@ -59,10 +59,6 @@ RCSID("$OpenBSD: session.c,v 1.188 2005/ #include "kex.h" #include "monitor_wrap.h" -#if defined(KRB5) && defined(USE_AFS) -#include -#endif - #ifdef GSSAPI #include "ssh-gss.h" #endif From dtucker at zip.com.au Sat Nov 12 19:34:28 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 12 Nov 2005 19:34:28 +1100 Subject: [PATCH] Use krb5-config if avaialable for Kerberos parameters Message-ID: <20051112083428.GA18277@gate.dodgy.net.au> Hi. I've had this patch a while (and I posted an earlier version a while back): it tries to use krb5-config to obtain the Kerberos build options. If it's not available, or isn't in the path specified to --with-kerberos5 then the existing behaviour is kept. It seems to work for me with MIT and Heimdal. I got some feedback from one person, would any of the Kerberos-using folk care to comment on it? -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. -------------- next part -------------- Index: configure.ac =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/configure.ac,v retrieving revision 1.307 diff -u -p -r1.307 configure.ac --- configure.ac 12 Nov 2005 07:42:37 -0000 1.307 +++ configure.ac 12 Nov 2005 08:25:35 -0000 @@ -2812,19 +2812,25 @@ AC_ARG_WITH(kerberos5, [ --with-kerberos5=PATH Enable Kerberos 5 support], [ if test "x$withval" != "xno" ; then if test "x$withval" = "xyes" ; then - KRB5ROOT="/usr/local" + # Check for a krb5-config in the path, if found use it + AC_PATH_PROG(KRB5CONF, krb5-config) + if test -x "$KRB5CONF" ; then + KRB5ROOT="`$KRB5CONF --path`" + else + KRB5ROOT="/usr/local" + KRB5CONF="/usr/local/bin/krb5-config" + fi else KRB5ROOT=${withval} + KRB5CONF="${withval}/bin/krb5-config" fi AC_DEFINE(KRB5, 1, [Define if you want Kerberos 5 support]) KRB5_MSG="yes" - AC_MSG_CHECKING(for krb5-config) - if test -x $KRB5ROOT/bin/krb5-config ; then - KRB5CONF=$KRB5ROOT/bin/krb5-config - AC_MSG_RESULT($KRB5CONF) - + AC_MSG_CHECKING(if $KRB5CONF is usable) + if test -x "$KRB5CONF" ; then + AC_MSG_RESULT(yes) AC_MSG_CHECKING(for gssapi support) if $KRB5CONF | grep gssapi >/dev/null ; then AC_MSG_RESULT(yes) From dtucker at zip.com.au Sat Nov 12 19:55:27 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 12 Nov 2005 19:55:27 +1100 Subject: [PATCH] Use krb5-config if avaialable for Kerberos parameters In-Reply-To: <20051112083428.GA18277@gate.dodgy.net.au> References: <20051112083428.GA18277@gate.dodgy.net.au> Message-ID: <20051112085527.GA18870@gate.dodgy.net.au> On Sat, Nov 12, 2005 at 07:34:28PM +1100, Darren Tucker wrote: > I've had this patch a while (and I posted an earlier version a while > back): it tries to use krb5-config to obtain the Kerberos build options. > If it's not available, or isn't in the path specified to --with-kerberos5 > then the existing behaviour is kept. Hm, that's not a very good explanation. Make that "tries to use krb5-config from the default path". Basically, it's trying to play nice in the case where you have a krb5-config in the default path, but the other parameters (include path and so forth) won't result in a working build. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From alon.barlev at gmail.com Wed Nov 16 08:36:18 2005 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Tue, 15 Nov 2005 23:36:18 +0200 Subject: PKCS#11 support for openssh In-Reply-To: <20051114204601.GH27257@deviate.cx> References: <20051113214910.GF27257@deviate.cx> <437842C6.6000609@gmail.com> <20051114200317.GG27257@deviate.cx> <4378EF5A.7090907@gmail.com> <20051114204601.GH27257@deviate.cx> Message-ID: <437A54D2.2090007@gmail.com> Dan C wrote: > Thanks for your quick reply. > > On Mon, Nov 14, 2005 at 10:11:06PM +0200, Alon Bar-Lev wrote: > >>Dan C wrote: >> >>>On Mon, Nov 14, 2005 at 09:54:46AM +0200, Alon Bar-Lev wrote: >>>Unfortunately I'm unable to use the OpenSC PKCS#11 provider as desired >>>with my card, as the manufacturer (Aladdin's eToken) does not use a >>>compliant layout. They have however recently developed their own >>>proprietary PKCS#11 module, so obviously I'm keen for OpenSSH PKCS#11 >>>support. >> >>But I heard of success in using eToken with OpenSC and >>PKCS#11 provider... >>Maybe you want to use the same content in Windows and >>Linux... Then I agree that it is not possible... > > > Yeah, that's correct. > > Previously I've been using a seperate card initialized with OpenSC's > pkcs15-init. But with Aladdin's upcoming PKCS#11 module, it would be > nice to consolidate all of my key usage onto one card. > > >>>I suspect that I'm not actually using your patch as intended though. >>>Should I still be able to, as previously with OpenSC - generate a self >>>signed certifcate with my existing RSA private key, import the pair to >>>my card and then reference the private key to log into my legacy SSH >>>hosts? >> >>Well... You need the X.509 patch for your host... I think >>that smartcards should be used with X.509... I have a >>discussion regarding this issue with OpenSSH developers... >> >>http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=113096115818802&w=2 >> >>Roumen Petrov does not support self-signed certificate in >>his X.509 patch implementation... I've asked him to... He is >>thinking on it.... >> >>So if you can use a certificate which is not self-signed... >>It would be the best... Until things will clear up. > > > Ah, I see - then I haven't been using it as intended. The existing > OpenSC support allows you to reference a private RSA key and a public > key in the form of a certificate generated against the private key (to > humour the smartcard structure), in order to authenticate against > standard SSH2 public-key hosts. No patching of remote hosts or amending > authorized_keys files. > > I agree with your reasoning for x509 over raw RSA support. But I think a > replacement of the existing OpenSC support would need to still handle > raw RSA. It would be invaluable for people with existing SSH2 PKI > environments. > > Regards, > Dan > Hello, Attached is an update to the PKCS#11 patch. It can now be applied as standalone without X.509 patch, but is X.509 patch aware. A valid X.509 certificate must still exist on the token, but without X.509 support it is exported as regular RSA key. There is a nice utility Timo Felbinger wrote (http://www.timof.qipc.org/x509toOpenSSH.c) that extracts ssh public key from X.509 certificate. If you like X.509 support apply the X.509 patch *AFTER* the PKCS#11 patch. There are minor rejects that can be easily corrected by: $ autoreconf -i -v The new patch also supports self-signed certificates. If it finds one it treats it as RSA key and not as X.509 RSA key, Roumen, I think this should be the default behavior of the X.509 patch. Waiting to receive many more comments... Best Regards, Alon Bar-Lev. From coderman at gmail.com Wed Nov 16 09:39:57 2005 From: coderman at gmail.com (coderman) Date: Tue, 15 Nov 2005 14:39:57 -0800 Subject: SSH with authentication and no privacy Message-ID: <4ef5fec60511151439se1f3e93r238cb7cdfd7a6d67@mail.gmail.com> Previous threads have discussed the now deprecated NONE cipher and the rationale for its removal. Recent posts on FCC compliance indicate the usefulness of authentication without privacy for packet radio. I also find this useful for transfers between IPsec protected endpoints. Authentication is then useful for user administration/privileges but encryption is not necessary given the IPsec transport. Is there a compromise that would be acceptable to the ssh maintainers which provides an authenticated ssh mode without privacy? IPsec has long been able to support such a mode (AH without ESP) and there is a legitimate need as mentioned before. Concern for accidental disclosure due to user error or misconfiguration is legitimate. Would the following changes be acceptable? - Require an ssh[d]_config option which explicitly allows authentication without privacy. This would be defaulted to off / commented in the example config files. - Require an ssh/scp/* flag on command line to enable authentication without privacy (in addition to config file approval). HPN uses the '-z' option. - When used in this mode a message would be printed to stderr indicating the lack of privacy. HPN prints a 'WARNING: ENABLED NULL CIPHER' for scp but not ssh. Perhaps 'WARNING: privacy is disabled, plaintext mode selected' would be more explanatory. I would be willing to work on such a patch if this would address maintainer concerns about unintended disclosure while providing the useful feature of authentication without privacy. Best regards, From dtucker at zip.com.au Tue Nov 15 07:10:23 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 15 Nov 2005 07:10:23 +1100 Subject: [PATCH] Use krb5-config if avaialable for Kerberos parameters In-Reply-To: References: <20051112083428.GA18277@gate.dodgy.net.au> <20051112085527.GA18870@gate.dodgy.net.au> Message-ID: <4378EF2F.8010804@zip.com.au> David Leonard wrote: > Well, that patch won't work with our krb5-config You'll get back an > empty string, since --path is not understood. :( > > That makes me wonder why the need to deduce KRB5ROOT anyway? Because some implementations don't have a krb5-config (eg OpenBSD's integrated Heimdal) and they work now. I didn't want to break working configurations. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From alon.barlev at gmail.com Wed Nov 16 19:07:20 2005 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Wed, 16 Nov 2005 10:07:20 +0200 Subject: PKCS#11 support for openssh In-Reply-To: <20051116010700.GA14039@deviate.cx> References: <20051113214910.GF27257@deviate.cx> <437842C6.6000609@gmail.com> <20051114200317.GG27257@deviate.cx> <4378EF5A.7090907@gmail.com> <20051114204601.GH27257@deviate.cx> <437A54D2.2090007@gmail.com> <20051116010700.GA14039@deviate.cx> Message-ID: <437AE8B8.8030904@gmail.com> Dan C wrote: > Alon, that's great - thank you for the update. It works perfectly in > keeping with the old OpenSC support, but with the added flexibility of > being able to use _any_ available PKCS#11 provider. A good improvement I > feel. > > My only remaining thoughts echo that of Andreas's, in that it would be > useful to have "direct" ssh(1) support. For both the ease of being able > to choose ie. "ssh -I0 " when you wish, as well as being able to > hardset options to use card auth for specified hosts in ssh_config(5). > > Please feel free to pass my comments on to the list/Roumen/Andreas and > by all means throw any further testing my way. > > Regards, > Dan Hello Dan, I am glad that all works! I agree that there should be a simple way to use ssh with smartcard support... But I don't like current implementation in which the code is written twice, once for the agent and second for the ssh. I think that ssh should always use the agent, and if not available execute it (Or convert the agent to a library). Then ssh can read the config file and add identities as if the agent is external. This way the private key handling will be implemented in one place.... When I get some kind of positive response from the openssh developers, I will discuses what the user interface of the PKCS#11 support should be and implement a more friendly interface. Best Regards, Alon Bar-Lev. From lists at dawes.za.net Wed Nov 16 22:21:19 2005 From: lists at dawes.za.net (Rogan Dawes) Date: Wed, 16 Nov 2005 13:21:19 +0200 Subject: OpenSSH on NCR MPRAS Message-ID: <437B162F.7010400@dawes.za.net> Hi folks, I have successfully compiled and run OpenSSH 4.1p1 on NCR MPRAS: $ uname -a UNIX_SV support1 4.0 3.0 3446 Pentium Pro(TM)-EISA/PCI $ However, I have found one pretty critical problem, arising from the way that MPRAS handles changes to the IP stack. Background: To update any of the IP or TCP configuration options, system administrators should use the program "tcpconfig". This prompts the admin for a bunch of options, and then, once they have been confirmed, it resets the ENTIRE IP stack, and applies the new settings. Clearly, this is not something that should be done remotely! However, the net result of this is that OpenSSH generates thousands of error messages in the "accept" loop, filling up the (prehistoric) syslog facility that has no concept of "previous message repeated 122342234 times"! This continues even after the IP stack has completed reloading. Question: Would it be unreasonable to add some kind of loop counter that tracks the number of consecutive accept errors, and if it reaches a certain threshold, restarts the daemon from a suitable point? Maybe it could only apply to MPRAS, if this is not a good option for other systems? Many thanks for your consideration. Rogan P.S. I did look at the diffs between 4.1p1 and current, and there does not seem to have been any activity in this regard. P.P.S Please copy me on responses, I am not subscribed to this list. From dtucker at zip.com.au Wed Nov 16 23:49:43 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 16 Nov 2005 23:49:43 +1100 Subject: OpenSSH on NCR MPRAS In-Reply-To: <437B162F.7010400@dawes.za.net> References: <437B162F.7010400@dawes.za.net> Message-ID: <20051116124943.GA20997@gate.dodgy.net.au> On Wed, Nov 16, 2005 at 01:21:19PM +0200, Rogan Dawes wrote: > To update any of the IP or TCP configuration options, system > administrators should use the program "tcpconfig". This prompts the > admin for a bunch of options, and then, once they have been confirmed, > it resets the ENTIRE IP stack, and applies the new settings. Clearly, > this is not something that should be done remotely! > > However, the net result of this is that OpenSSH generates thousands of > error messages in the "accept" loop, filling up the (prehistoric) syslog > facility that has no concept of "previous message repeated 122342234 times"! > > This continues even after the IP stack has completed reloading. > > Question: > > Would it be unreasonable to add some kind of loop counter that tracks > the number of consecutive accept errors, and if it reaches a certain > threshold, restarts the daemon from a suitable point? It would not be hard, but it seems like an awful hack. How do the native utilities behave under those circumstances? The following patch ought to do it (against 4.2p1). You will need to either rebuild configure with autoconf or add "-DBROKEN_ACCEPT" to your CFLAGS. Index: configure.ac =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/configure.ac,v retrieving revision 1.292 diff -u -p -r1.292 configure.ac --- configure.ac 31 Aug 2005 16:59:49 -0000 1.292 +++ configure.ac 16 Nov 2005 12:44:59 -0000 @@ -418,6 +418,7 @@ mips-sony-bsd|mips-sony-newsos4) AC_DEFINE(SETEUID_BREAKS_SETUID) AC_DEFINE(BROKEN_SETREUID) AC_DEFINE(BROKEN_SETREGID) + AC_DEFINE(BROKEN_ACCEPT, 1, [broken accept]) ;; *-sni-sysv*) # /usr/ucblib MUST NOT be searched on ReliantUNIX Index: sshd.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/sshd.c,v retrieving revision 1.313 diff -u -p -r1.313 sshd.c --- sshd.c 26 Jul 2005 11:54:56 -0000 1.313 +++ sshd.c 16 Nov 2005 12:44:25 -0000 @@ -1434,6 +1434,14 @@ main(int ac, char **av) error("accept: %.100s", strerror(errno)); continue; } +#ifdef BROKEN_ACCEPT + if (errno == ENXIO) { + static int enxio_count = 0; + + if (enxio_count++ > 10000) + received_sighup = 1; + } +#endif if (unset_nonblock(newsock) == -1) { close(newsock); continue; -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From lists at dawes.za.net Wed Nov 16 23:53:55 2005 From: lists at dawes.za.net (Rogan Dawes) Date: Wed, 16 Nov 2005 14:53:55 +0200 Subject: OpenSSH on NCR MPRAS In-Reply-To: <20051116124943.GA20997@gate.dodgy.net.au> References: <437B162F.7010400@dawes.za.net> <20051116124943.GA20997@gate.dodgy.net.au> Message-ID: <437B2BE3.5040504@dawes.za.net> Darren Tucker wrote: > On Wed, Nov 16, 2005 at 01:21:19PM +0200, Rogan Dawes wrote: > >>To update any of the IP or TCP configuration options, system >>administrators should use the program "tcpconfig". This prompts the >>admin for a bunch of options, and then, once they have been confirmed, >>it resets the ENTIRE IP stack, and applies the new settings. Clearly, >>this is not something that should be done remotely! >> >>However, the net result of this is that OpenSSH generates thousands of >>error messages in the "accept" loop, filling up the (prehistoric) syslog >>facility that has no concept of "previous message repeated 122342234 times"! >> >>This continues even after the IP stack has completed reloading. >> >>Question: >> >>Would it be unreasonable to add some kind of loop counter that tracks >>the number of consecutive accept errors, and if it reaches a certain >>threshold, restarts the daemon from a suitable point? > > > It would not be hard, but it seems like an awful hack. How do the > native utilities behave under those circumstances? > They seem to handle it well enough, apparently. The alternative is to run OpenSSH from inetd, if I can find out how to make my changes persistent! It may be cleaner in the long run. Thanks for the speedy patch. I thought that the received_sighup would have a role to play somehow. Rogan From dtucker at zip.com.au Wed Nov 16 23:59:14 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 16 Nov 2005 23:59:14 +1100 Subject: OpenSSH on NCR MPRAS In-Reply-To: <20051116124943.GA20997@gate.dodgy.net.au> References: <437B162F.7010400@dawes.za.net> <20051116124943.GA20997@gate.dodgy.net.au> Message-ID: <20051116125914.GA21322@gate.dodgy.net.au> On Wed, Nov 16, 2005 at 11:49:43PM +1100, Darren Tucker wrote: > The following patch ought to do it (against 4.2p1). You will need > to either rebuild configure with autoconf or add "-DBROKEN_ACCEPT" > to your CFLAGS. And now a patch that has a chance of working.... Index: configure.ac =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/configure.ac,v retrieving revision 1.292 diff -u -p -r1.292 configure.ac --- configure.ac 31 Aug 2005 16:59:49 -0000 1.292 +++ configure.ac 16 Nov 2005 12:44:59 -0000 @@ -418,6 +418,7 @@ mips-sony-bsd|mips-sony-newsos4) AC_DEFINE(SETEUID_BREAKS_SETUID) AC_DEFINE(BROKEN_SETREUID) AC_DEFINE(BROKEN_SETREGID) + AC_DEFINE(BROKEN_ACCEPT, 1, [broken accept]) ;; *-sni-sysv*) # /usr/ucblib MUST NOT be searched on ReliantUNIX Index: sshd.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/sshd.c,v retrieving revision 1.313 diff -u -p -r1.313 sshd.c --- sshd.c 26 Jul 2005 11:54:56 -0000 1.313 +++ sshd.c 16 Nov 2005 12:57:14 -0000 @@ -1429,6 +1429,14 @@ main(int ac, char **av) fromlen = sizeof(from); newsock = accept(listen_socks[i], (struct sockaddr *)&from, &fromlen); +#ifdef BROKEN_ACCEPT + if (errno == ENXIO) { + static int enxio_count = 0; + + if (enxio_count++ > 10000) + received_sighup = 1; + } +#endif if (newsock < 0) { if (errno != EINTR && errno != EWOULDBLOCK) error("accept: %.100s", strerror(errno)); -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From maniac.nl at gmail.com Thu Nov 17 01:32:39 2005 From: maniac.nl at gmail.com (Mark Janssen) Date: Wed, 16 Nov 2005 15:32:39 +0100 Subject: Amateur Radio/FCC and the "none" encryption option In-Reply-To: References: Message-ID: <531e3e4c0511160632h7c0c8d30k765cba91487db8d6@mail.gmail.com> On 11/11/05, Curt, WE7U wrote: > On Wed, 9 Nov 2005, Curt, WE7U wrote: > > > Is there an easy way to get the "none" option back into OpenSSH? In > > order to do TCP/IP over amateur radio in the U.S. (and most other > > countries) we must not use encryption to obscure the meaning of our > > info, but we are allowed to use authentication to set up the links. > Is there no answer back from the devel. team on this one? We've > been struggling to keep this option compiled in and it's been > getting harder to find old enough versions that the patches will > apply to, and harder to compile such on newer systems. Don't the high-performance networking patch guys also keep a none option available. afaik they have working patches for the latest and greatest openssh versions. > I got one reply off-sig from someone who keeps newer patches > available, but why should this be necessary? If there's a > demonstrated need from some group of users can't this function be > included in the sources as it used to be? It can be made more > difficult to accidentally compile in as a default, perhaps a > special #define or something that needs to be set or uncommented. No comment here... developer decision ;) But I wouldn't mind if the none version from hpn would be included... as long as it's never ever used as a default :) and prints a huge warning if it ever is used without some switch/configoption to disable the warning ;) > Again, this is for use over amateur radio links, and the FCC doesn't > allow us to encrypt over radio links. We're allowed to > authenticate, but not encrypt the data over a link. That sucks ;) -- Mark Janssen -- maniac(at)maniac.nl -- pgp: 0x357D2178 | ,''`. | Unix / Linux Open-Source and Internet Consultant @ Snow.nl | : :' : | Maniac.nl MarkJanssen.nl NerdNet.nl Unix.nl | `. `' | Skype: markmjanssen ICQ: 129696007 irc: FooBar on undernet | `- | From David.Leonard at quest.com Mon Nov 14 10:38:00 2005 From: David.Leonard at quest.com (David Leonard) Date: Mon, 14 Nov 2005 09:38:00 +1000 (EST) Subject: [PATCH] Use krb5-config if avaialable for Kerberos parameters In-Reply-To: <20051112085527.GA18870@gate.dodgy.net.au> References: <20051112083428.GA18277@gate.dodgy.net.au> <20051112085527.GA18870@gate.dodgy.net.au> Message-ID: Well, that patch won't work with our krb5-config You'll get back an empty string, since --path is not understood. :( That makes me wonder why the need to deduce KRB5ROOT anyway? How about logic like this, instead: --with-kerberos5=/some/path * error unless /some/path/bin/krb5-config exists * use `/some/path/bin/krb5-config --cflags` etc --with-kerberos5=yes * error unless krb5-config found in $PATH * use `krb5-config --cflags` etc plus, perhaps: --with-kerberos5=auto * if krb5-config found in $PATH use `krb5-config --cflags` etc d On Sat, 12 Nov 2005, Darren Tucker wrote: > On Sat, Nov 12, 2005 at 07:34:28PM +1100, Darren Tucker wrote: > > I've had this patch a while (and I posted an earlier version a while > > back): it tries to use krb5-config to obtain the Kerberos build options. > > If it's not available, or isn't in the path specified to --with-kerberos5 > > then the existing behaviour is kept. > > Hm, that's not a very good explanation. Make that "tries to use > krb5-config from the default path". > > Basically, it's trying to play nice in the case where you have a > krb5-config in the default path, but the other parameters (include path > and so forth) won't result in a working build. > > -- David Leonard Vintela Resource Central software engineer Quest Software; 303 Adelaide St, Brisbane, Australia; www.quest.com Phone: (US) +1 801 655 2755 (AU) +61 7 3023 5133 From openssh at roumenpetrov.info Thu Nov 17 09:40:48 2005 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Thu, 17 Nov 2005 00:40:48 +0200 Subject: PKCS#11 support for openssh In-Reply-To: <437A54D2.2090007@gmail.com> References: <20051113214910.GF27257@deviate.cx> <437842C6.6000609@gmail.com> <20051114200317.GG27257@deviate.cx> <4378EF5A.7090907@gmail.com> <20051114204601.GH27257@deviate.cx> <437A54D2.2090007@gmail.com> Message-ID: <437BB570.7070006@roumenpetrov.info> Alon, you should improve security of code. I already sent some notes offlist. Alon Bar-Lev wrote: > Dan C wrote: > >> Thanks for your quick reply. >> >> On Mon, Nov 14, 2005 at 10:11:06PM +0200, Alon Bar-Lev wrote: >> >>> Dan C wrote: >>> >>>> On Mon, Nov 14, 2005 at 09:54:46AM +0200, Alon Bar-Lev wrote: >>>> Unfortunately I'm unable to use the OpenSC PKCS#11 provider as desired >>>> with my card, as the manufacturer (Aladdin's eToken) does not use a >>>> compliant layout. They have however recently developed their own >>>> proprietary PKCS#11 module, so obviously I'm keen for OpenSSH PKCS#11 >>>> support. >>> >>> >>> But I heard of success in using eToken with OpenSC and PKCS#11 >>> provider... >>> Maybe you want to use the same content in Windows and Linux... Then I >>> agree that it is not possible... >> >> >> >> Yeah, that's correct. >> >> Previously I've been using a seperate card initialized with OpenSC's >> pkcs15-init. But with Aladdin's upcoming PKCS#11 module, it would be >> nice to consolidate all of my key usage onto one card. >> >> >>>> I suspect that I'm not actually using your patch as intended though. >>>> Should I still be able to, as previously with OpenSC - generate a self >>>> signed certifcate with my existing RSA private key, import the pair to >>>> my card and then reference the private key to log into my legacy SSH >>>> hosts? >>> >>> >>> Well... You need the X.509 patch for your host... I think that >>> smartcards should be used with X.509... I have a discussion regarding >>> this issue with OpenSSH developers... >>> >>> http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=113096115818802&w=2 >>> >>> Roumen Petrov does not support self-signed certificate in his X.509 >>> patch implementation... I've asked him to... He is thinking on it.... >>> >>> So if you can use a certificate which is not self-signed... It would >>> be the best... Until things will clear up. >> >> >> >> Ah, I see - then I haven't been using it as intended. The existing >> OpenSC support allows you to reference a private RSA key and a public >> key in the form of a certificate generated against the private key (to >> humour the smartcard structure), in order to authenticate against >> standard SSH2 public-key hosts. No patching of remote hosts or amending >> authorized_keys files. >> >> I agree with your reasoning for x509 over raw RSA support. But I think a >> replacement of the existing OpenSC support would need to still handle >> raw RSA. It would be invaluable for people with existing SSH2 PKI >> environments. >> >> Regards, >> Dan >> > > Hello, > > Attached is an update to the PKCS#11 patch. It can now be applied as > standalone without X.509 patch, but is X.509 patch aware. > > A valid X.509 certificate must still exist on the token, but without > X.509 support it is exported as regular RSA key. > > There is a nice utility Timo Felbinger wrote > (http://www.timof.qipc.org/x509toOpenSSH.c) that extracts ssh public key > from X.509 certificate. > > If you like X.509 support apply the X.509 patch *AFTER* the PKCS#11 > patch. There are minor rejects that can be easily corrected by: > $ autoreconf -i -v > > The new patch also supports self-signed certificates. If it finds one it > treats it as RSA key and not as X.509 RSA key, Roumen, I think this > should be the default behavior of the X.509 patch. > > Waiting to receive many more comments... > > Best Regards, > Alon Bar-Lev. From Jason.C.Burns at wellsfargo.com Thu Nov 17 11:06:27 2005 From: Jason.C.Burns at wellsfargo.com (Jason.C.Burns at wellsfargo.com) Date: Wed, 16 Nov 2005 18:06:27 -0600 Subject: 4.2 and the 'last' command Message-ID: We've run into an interesting dilemma regarding last log information and ssh 4.2p1. In 3.8, we didn't see this problem, but now has cropped up in 4.2. When a user logs in, sshd seems to call 'last' to get the last log information. 'last' then opens the /var/log/wtmp file and processes the information. On some systems, this file can be quite large, and we're seeing login times of upwards around a minute while 'last' pegs the system resources. My question: I can't find in the source where 'last' is explicitly called, so is there an API call that was added between these versions that would refer the system to 'last'? I've noticed a function 'login_get_lastlog' that seems to get the information with it's own algo, but I didn't see an option in the config to turn that on. I only found the option to turn last log information completely off, and unfortunately that's not an option. Anybody have any other ideas on where to go to find where 'last' is being called, or any other ideas on how to optimize it? Thanks! Jason From dtucker at zip.com.au Thu Nov 17 13:23:41 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 17 Nov 2005 13:23:41 +1100 Subject: 4.2 and the 'last' command In-Reply-To: References: Message-ID: <437BE9AD.3050902@zip.com.au> Jason.C.Burns at wellsfargo.com wrote: > My question: I can't find in the source where 'last' is explicitly > called, so is there an API call that was added between these versions > that would refer the system to 'last'? Depends. What platform are you running, and which build and run-time options have you enabled? AFAIK sshd doesn't exec "last" itself, although it's possible that something it calls does under the covers. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From demolish at kiwi-fraser.net Thu Nov 17 23:50:53 2005 From: demolish at kiwi-fraser.net (Donald Fraser) Date: Thu, 17 Nov 2005 12:50:53 -0000 Subject: AllowUsers not working under certain conditions Message-ID: <005c01c5eb75$8b9d25c0$0264a8c0@demolish1> Hello, I've trawled archives looking for changes in the "AllowUsers" option, manuals, changes log, reported bugs and to my surprise I can't find anything or anyone that has reported the issues that I am experiencing. I am using the default installation sshd_config file as supplied by Redhat and the only options I have changed are: ListenAddress AllowUsers The first problem exists on both of the following versions oppenssh-3.5p1 and oppenssh-3.9p1 1) I have on one of our servers the line in the sshd_config file: AllowUsers root at 192.168.100.* root at 192.168.102.* The server that runs the sshd only allows ssh clients to connect from the sub-net 192.168.100.0/24. Where as one would expect it to allow connections from both the listed sub-nets 192.168.100.0/24 and 192.168.102.0/24. Basically if I try connecting from the 192.168.102.0/24 sub-net I get the "User root not allowed because not listed in AllowUsers" error. The weird thing here is that if I change the option: ListenAddress :: to ListenAddress my-server then the problem goes away. There appears to be nothing in the documentation that suggests the ListenAddress setting effects the AllowUsers setting. The second problem is not present on the oppenssh-3.5p1-6 but is present on the later version oppenssh-3.9p1-8. The problem has arisen after upgrading from Redhat Linux 9 (oppenssh-3.5p1-6) to Redhat Enterprise Linux 4 (oppenssh-3.9p1-8.RHEL4.1) 2) I have on one of our servers the line in the sshd_config file: AllowUsers root at 192.168.100.12 root@*.mycompany.com donald at 192.168.100.99 donald@*mydomain.com User root can log on from the specified IP address or any domain which matches the pattern *.mycompany.com. Note that the *.mycompany.com domains are all machines on a local sub-net with their domain names specified in the /etc/hosts file. The user donald can connect from the local sub-net specified IP address but cannot connect from an external domain that matches the pattern *mydomain.com. The only way I can get the user donald to connect on the external domain is by putting the exact IP address in the AllowUsers option, which is not particularly useful as it is a dynamically changing IP address. As I have already stated, the exact same AllowUsers option used to work fine under the older (3.5p1) version of openssh. I tried setting the option UseDNS to no but that makes no difference. Can somebody tell me if these are known problems or simply features (that's the way its supposed to work)? If they are known or new problems are they likely to be fixed in the latest version? Regards Donald Fraser Ps I particularly like the idea put forward by Patrick Gosling on 2005-01-20 10:27:17 titled: AllowUsers - proposal for useful variations on the theme From dtucker at zip.com.au Fri Nov 18 00:21:13 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 18 Nov 2005 00:21:13 +1100 Subject: AllowUsers not working under certain conditions In-Reply-To: <005c01c5eb75$8b9d25c0$0264a8c0@demolish1> References: <005c01c5eb75$8b9d25c0$0264a8c0@demolish1> Message-ID: <20051117132113.GA16630@gate.dodgy.net.au> On Thu, Nov 17, 2005 at 12:50:53PM -0000, Donald Fraser wrote: [...] > The first problem exists on both of the following versions oppenssh-3.5p1 > and oppenssh-3.9p1 > 1) I have on one of our servers the line in the sshd_config file: > AllowUsers root at 192.168.100.* root at 192.168.102.* > > The server that runs the sshd only allows ssh clients to connect from the > sub-net 192.168.100.0/24. > Where as one would expect it to allow connections from both the listed > sub-nets 192.168.100.0/24 and 192.168.102.0/24. > Basically if I try connecting from the 192.168.102.0/24 sub-net I get the > "User root not allowed because not listed in AllowUsers" error. > > The weird thing here is that if I change the option: > "ListenAddress ::" to "ListenAddress my-server" > then the problem goes away. The problem is that when you specify "::" as the ListenAddress, the kernel is reporting IPv4 connections as IP4-in-6 mapped ones (ie ::ffff:xxxx), which don't match the IP addresses you specified. If you specify the IPv6 addresses the kernel reports to sshd then it will work. OpenSSH 4.1 and up work around this by "normalising" the addresses first. From the ChangeLog: - (dtucker) [canohost.c] normalise socket addresses returned by get_remote_hostname(). This means that IPv4 addresses in log messages on IPv6 enabled machines will no longer be prefixed by "::ffff:" and AllowUsers, DenyUsers, AllowGroups, DenyGroups will match IPv4-style addresses only for 4-in-6 mapped connections, regardless of whether or not the machine is IPv6 enabled. ok djm@ And the trivial patch: diff -u openssh_cvs/canohost.c:1.47 openssh_cvs/canohost.c:1.48 --- openssh_cvs/canohost.c:1.47 Tue Mar 1 21:16:19 2005 +++ openssh_cvs/canohost.c Tue May 3 19:05:32 2005 @@ -251,6 +251,8 @@ if (addr.ss_family == AF_INET6) addrlen = sizeof(struct sockaddr_in6); + ipv64_normalise_mapped(&addr, &addrlen); + /* Get the address in ascii. */ if ((r = getnameinfo((struct sockaddr *)&addr, addrlen, ntop, sizeof(ntop), NULL, 0, flags)) != 0) { > The second problem is not present on the oppenssh-3.5p1-6 but is present on > the later version oppenssh-3.9p1-8. [snip description] An explanation for this one does not immediately spring to mind. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From stuge-openssh-unix-dev at cdy.org Fri Nov 18 05:55:13 2005 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Thu, 17 Nov 2005 19:55:13 +0100 Subject: AllowUsers not working under certain conditions In-Reply-To: <005c01c5eb75$8b9d25c0$0264a8c0@demolish1> References: <005c01c5eb75$8b9d25c0$0264a8c0@demolish1> <20051117132113.GA16630@gate.dodgy.net.au> <005c01c5eb75$8b9d25c0$0264a8c0@demolish1> Message-ID: <20051117185513.32055.qmail@cdy.org> On Thu, Nov 17, 2005 at 12:50:53PM -0000, Donald Fraser wrote: > The user donald can connect from the local sub-net specified IP > address but cannot connect from an external domain that matches the > pattern *mydomain.com. The only way I can get the user donald to > connect on the external domain is by putting the exact IP address > in the AllowUsers option, which is not particularly useful as it is > a dynamically changing IP address. Does the PTR record for the IP address change along with the A record for the name? I assume sshd does a reverse-lookup of the IP-adress, otherwise it would be completely trivial to bypass the check. //Peter From demolish at kiwi-fraser.net Fri Nov 18 05:55:03 2005 From: demolish at kiwi-fraser.net (Donald Fraser) Date: Thu, 17 Nov 2005 18:55:03 -0000 Subject: AllowUsers not working under certain conditions References: <005c01c5eb75$8b9d25c0$0264a8c0@demolish1> <20051117132113.GA16630@gate.dodgy.net.au> Message-ID: <003101c5eba8$6d8011f0$0264a8c0@demolish1> Thanks for the reply Darren, Darren Tucker wrote: > On Thu, Nov 17, 2005 at 12:50:53PM -0000, Donald Fraser wrote: > [...] > > The second problem is not present on the oppenssh-3.5p1-6 but is present on > > the later version oppenssh-3.9p1-8. > [snip description] > > An explanation for this one does not immediately spring to mind. The first problem I can live with, as there is a way around that one. The second is not so easy to live with, I therefore have included the output of the log that shows where it is failing. I cut the log down to show the differences between failure and pass, rather than the whole log file which tends to be rather large: Nov 17 14:26:40 develop sshd[9301]: debug3: monitor_read: checking request 7 Nov 17 14:26:40 develop sshd[9301]: debug3: mm_answer_pwnamallow Nov 17 14:26:40 develop sshd[9301]: User AUser not allowed because not listed in AllowUsers Nov 17 14:26:40 develop sshd[9301]: debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 0 Nov 17 14:26:40 develop sshd[9301]: debug3: mm_request_send entering: type 8 and when it passes by placing the exact IP address in the AllowUsers section. Nov 17 16:45:13 develop sshd[9575]: debug3: monitor_read: checking request 7 Nov 17 16:45:13 develop sshd[9575]: debug3: mm_answer_pwnamallow Nov 17 16:45:13 develop sshd[9575]: debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1 Nov 17 16:45:13 develop sshd[9575]: debug3: mm_request_send entering: type 8 Additional notes: The user name "AUser" in the AllowUsers section does contain Upper and Lower case letters. The domain name returned from the reverse IP address look-up is of the form: IP-IP-IP-IP.dyn.somedomain.com, where IP are numbers that represent the IP address. If you think having the whole log will be of help then I can attach that. In the mean time I'll try and pin point the problem further by looking at the code myself. Regards Donald Fraser From rapier at psc.edu Fri Nov 18 06:28:52 2005 From: rapier at psc.edu (Chris Rapier) Date: Thu, 17 Nov 2005 14:28:52 -0500 Subject: Amateur Radio/FCC and the "none" encryption option In-Reply-To: <531e3e4c0511160632h7c0c8d30k765cba91487db8d6@mail.gmail.com> References: <531e3e4c0511160632h7c0c8d30k765cba91487db8d6@mail.gmail.com> Message-ID: <437CD9F4.7000805@psc.edu> > > Don't the high-performance networking patch guys also keep a none > option available. afaik they have working patches for the latest and > greatest openssh versions. Yes we do. It uises cipher switching so the authentication is still encrypted using the default cipher or whatever is specified with the -c option. After authentication takes place we switch over to the NONE cipher. > No comment here... developer decision ;) But I wouldn't mind if the > none version from hpn would be included... as long as it's never ever > used as a default :) and prints a huge warning if it ever is used > without some switch/configoption to disable the warning ;) Well, its perfectly understandable if the decision is made not to incorporate the NONE cipher switch we use. I've always fel the primary mission of OpenSSH is security and all decisions have to be made with that in mind. While we don't see the NONE switch as a big deal it is, without a doubt, a possible source of problems for less than vigilant users. We do print out a warning we the NONE switch takes place and we also have some safeguards in place to make sure it is not used with an interactive shell but nothing is 100%, ya know? From alon.barlev at gmail.com Fri Nov 18 23:26:59 2005 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Fri, 18 Nov 2005 14:26:59 +0200 Subject: PKCS#11 support for openssh In-Reply-To: <437BB570.7070006@roumenpetrov.info> References: <20051113214910.GF27257@deviate.cx> <437842C6.6000609@gmail.com> <20051114200317.GG27257@deviate.cx> <4378EF5A.7090907@gmail.com> <20051114204601.GH27257@deviate.cx> <437A54D2.2090007@gmail.com> <437BB570.7070006@roumenpetrov.info> Message-ID: <437DC893.1030409@gmail.com> Roumen Petrov wrote: > Alon, > > you should improve security of code. I already sent some notes offlist. > > Hello, Attached is a new version modified according to Roumen Petrov's helpful comments. For those of you that did not follow this thread: The PKCS#11 patch modify ssh-add and ssh-agent to support PKCS#11 private keys and certificates. It allows using multiple PKCS#11 providers at the same time, selecting keys by id, label or certificate subject, handling card removal and card insert events, handling card re-insert to a different slot, supporting session expiration. A valid X.509 certificate should exist on the token, without X.509 support it is exported as regular RSA key. Self-signed certificates are treated as RSA key and not as X.509 RSA key. There is a simple utility Timo Felbinger wrote (http://www.timof.qipc.org/x509toOpenSSH.c) that extracts ssh public key from X.509 certificate. If you like X.509 support apply the X.509 patch *AFTER* the PKCS#11 patch. There are minor rejects that can be easily corrected by: $ autoreconf -i -v One significant change is that the ssh-agent prompts for passwords now... So you need to configure it with a program that asks for card insert or PIN, a program such as x11-ssh-askpass. Current implementation (ssh-add asks for passwords) is not valid for dynamic smartcard environment. Current implementation uses the askpin program also for prompting card insert... Don't be confused, it only expects ok or cancel, attached is a simple scripts that uses kde in order to display these dialogs. A common scenario is the following: $ ssh-agent xterm -> $ ssh-add --pkcs11-ask-pin `which openssh-kde-dialogs.sh` $ ssh-add --pkcs11-add-provider --pkcs11-provider /usr/lib/pkcs11/MyProvider.so $ ssh-add --pkcs11-add-id --pkcs11-slot-type label --pkcs11-slot "MyToken" --pkcs11-id-type subject --pkcs11-id "/C=XX/CN=YY" $ ssh myhost In order to see available objects, you can use: $ ssh-add --pkcs11-show-slots --pkcs11-provider /usr/lib/pkcs11/MyProvider.so $ ssh-add --pkcs11-show-objects --pkcs11-provider /usr/lib/pkcs11/MyProvider.so --pkcs11-slot 0 I will be happy to receive any more comments! Best Regards, Alon Bar-Lev. From demolish at kiwi-fraser.net Fri Nov 18 23:43:18 2005 From: demolish at kiwi-fraser.net (Donald Fraser) Date: Fri, 18 Nov 2005 12:43:18 -0000 Subject: AllowUsers not working under certain conditions References: <005c01c5eb75$8b9d25c0$0264a8c0@demolish1><20051117132113.GA16630@gate.dodgy.net.au><005c01c5eb75$8b9d25c0$0264a8c0@demolish1> <20051117185513.32055.qmail@cdy.org> Message-ID: <006c01c5ec3d$a80f6ab0$0264a8c0@demolish1> > On Thu, Nov 17, 2005 at 12:50:53PM -0000, Donald Fraser wrote: > > The user donald can connect from the local sub-net specified IP > > address but cannot connect from an external domain that matches the > > pattern *mydomain.com. The only way I can get the user donald to > > connect on the external domain is by putting the exact IP address > > in the AllowUsers option, which is not particularly useful as it is > > a dynamically changing IP address. Peter Stuge wrote: > Does the PTR record for the IP address change along with the > A record for the name? I assume sshd does a reverse-lookup of the > IP-adress, otherwise it would be completely trivial to bypass the > check. I'm not exactly up on the terminology of the components of DNS entries but given an IP address the name returned is of the form: IP-IP-IP-IP.dyn.somedomain.com. However the reverse lookup of the name to IP address returns nothing, i.e. it doesn't exist in the DNS. Having looked at the code, this is where the problem lies. In version 3.5p1 there was the following option VerifyReverseMapping Specifies whether sshd should try to verify the remote host name and check that the resolved host name for the remote IP address maps back to the very same IP address. The default is no Some time after the above version and before or in version 3.9p1 the above option was removed and replaced by the following option: UseDNS Specifies whether sshd should lookup the remote host name and check that the resolved host name for the remote IP address maps back to the very same IP address. The default is yes Now the two options look very similar but having examined the code they are clearly not! The new UseDNS option when set to "no" means that given an IP address the host name will not be looked up, and therefore the host name will default to the IP address. Therefore domain names of any sort in your AllowUsers option will never work! I think the manual should be more clear on this. When the UseDNS option is set to "yes", given an IP address the host name will be looked but an addtional check - the resolved host name for the remote IP address maps back to the very same IP address is performed - whether you like it or not! Therefore what use to be a default of "no" for VerifyReverseMapping now defaults to "yes" if you want to use domain names in your AllowUsers option! Again this is not clear in the manual. I find this sort of change in behaviour frustrating to say the least! Why remove an option that defaulted to "no" and force one to use it - doesn't this take away the flexibility of the software? If security is what is at stake here then in order to user the software in the same way I am now, in fact, forced to reduce my level of security. Before I could use the option: AllowUsers Auser@*.somedomain.com One has to admit that, whilst having reverse mappping turned off, this is far more secure than the option I'm now forced to use to achieve the same of: AllowUsers Auser@* Does anybody know whether the VerifyReverseMapping option is going to be put back and what the reason for removing it in the first place was? Regards Donald Fraser From rob at cobrasales.com Sat Nov 19 05:04:27 2005 From: rob at cobrasales.com (Robert Bates (Cobra Powersports)) Date: Fri, 18 Nov 2005 13:04:27 -0500 Subject: SSH lib for Win32...? Message-ID: <191001c5ec6a$84122f80$6501a8c0@toshibauser> Hi there! I'm researching a project for my company that would involve a proprietary SSH tunnel client running on Win32. I was wondering if OpenSSH had a portable library component that I could leverage to manage the connection and tunneling functionality without any interface components...? Thanks in advance for any help or direction you can provide! ========== Robert Bates Cobra Powersports * http://www.cobrasales.com rob at cobrasales.com * 713-866-6262 x109 From stuge-openssh-unix-dev at cdy.org Sat Nov 19 06:20:21 2005 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Fri, 18 Nov 2005 20:20:21 +0100 Subject: AllowUsers not working under certain conditions In-Reply-To: <006c01c5ec3d$a80f6ab0$0264a8c0@demolish1> References: <20051117185513.32055.qmail@cdy.org> <006c01c5ec3d$a80f6ab0$0264a8c0@demolish1> Message-ID: <20051118192021.14634.qmail@cdy.org> On Fri, Nov 18, 2005 at 12:43:18PM -0000, Donald Fraser wrote: > > Does the PTR record for the IP address change along with the > > A record for the name? I assume sshd does a reverse-lookup of the > > IP-adress, otherwise it would be completely trivial to bypass the > > check. > > I'm not exactly up on the terminology of the components of DNS > entries but given an IP address the name returned is of the form: > IP-IP-IP-IP.dyn.somedomain.com. A is for name->IP. PTR is for IP->name, or "reverse" lookup. The name you show above is in the PTR record. And while you can have donald.yourdomain.com point to the IP, the IP doesn't resolve back to donald.yourdomain.com but instead to IP-IP-IP-IP.dyn.somedomain.com. > However the reverse lookup of the name to IP address returns > nothing, i.e. it doesn't exist in the DNS. > Having looked at the code, this is where the problem lies. Yep. [..VerifyReverseMapping vs UseDNS..] > I find this sort of change in behaviour frustrating to say the > least! Why remove an option that defaulted to "no" and force one to > use it - doesn't this take away the flexibility of the software? > > If security is what is at stake here then in order to user the > software in the same way I am now, in fact, forced to reduce my > level of security. I'm pretty sure your guess is spot on. The possibility to disable verification of IP-addresses vs. hostnames was likely removed because, as I wrote, without that verification it is trivial for anyone in control of a DNS-server serving PTR records to spoof their connection as being from your allowed domain. > Before I could use the option: > AllowUsers Auser@*.somedomain.com > One has to admit that, whilst having reverse mappping turned off, > this is far more secure than the option I'm now forced to use to > achieve the same of: > AllowUsers Auser@* I'm afraid not. DNS is not a secure system and anything that trusts DNS will be vulnerable to all problems that DNS is vulnerable to. > Does anybody know whether the VerifyReverseMapping option is going > to be put back and what the reason for removing it in the first > place was? I doubt it will return. May I suggest that you switch to using public key authetication and disable the password and keyboard-interactive authentication methods? I was afraid that my users would dislike that, but they didn't mind. Some even appreciated the opportunity to learn how nice agent forwarding is. :) //Peter From carson at taltos.org Sat Nov 19 09:48:29 2005 From: carson at taltos.org (Carson Gaspar) Date: Fri, 18 Nov 2005 17:48:29 -0500 Subject: AllowUsers not working under certain conditions In-Reply-To: <006c01c5ec3d$a80f6ab0$0264a8c0@demolish1> References: <005c01c5eb75$8b9d25c0$0264a8c0@demolish1> <20051117132113.GA16630@gate.dodgy.net.au> <005c01c5eb75$8b9d25c0$0264a8c0@demolish1> <20051117185513.32055.qmail@cdy.org> <006c01c5ec3d$a80f6ab0$0264a8c0@demolish1> Message-ID: --On Friday, November 18, 2005 12:43:18 PM +0000 Donald Fraser wrote: > If security is what is at stake here then in order to user the software in > the same way I am now, in fact, forced to reduce my level of security. > Before I could use the option: > AllowUsers Auser@*.somedomain.com > One has to admit that, whilst having reverse mappping turned off, this is > far more secure than the option I'm now forced to use to achieve the same > of: > AllowUsers Auser@* > > Does anybody know whether the VerifyReverseMapping option is going to be > put back and what the reason for removing it in the first place was? The OpenSSH developers tend to not allow people to do things that aren't secure (thus removal of the NONE cipher, etc.). Personally, I disagree with this "mother knows best" attitude, but I do understand it. Trusting DNS for access control is A Very Bad Idea. Doing so without verifying that the name hasn't been spoofed is just insane. I wouldn't allow Auser@*, I'd require Auser to fix his or her broken DNS (or switch ISPs), but then I'm a BOFH ;-) Can you please describe the problem you're trying to solve? I solved something that I _think_ is similar by writing the auth vector patch, and required HostBasedAuth before a user could enter a password. I was attempting to prevent brute force password guessing attacks from random Internet hosts. Sadly that patch would now probably have to be re-written from scratch, as the code has changed a fair amount. Assuming some similar patch were written, it would be sensible to use the name presented as part of HostBasedAuth for use with AllowUsers. This would give you the granularity you appear to want, with some actual security. It _would_ require maintaining the remote hosts' public keys on your server, however. -- Carson From demolish at kiwi-fraser.net Sat Nov 19 14:37:42 2005 From: demolish at kiwi-fraser.net (Donald Fraser) Date: Sat, 19 Nov 2005 03:37:42 -0000 Subject: AllowUsers not working under certain conditions References: <20051117185513.32055.qmail@cdy.org><006c01c5ec3d$a80f6ab0$0264a8c0@demolish1> <20051118192021.14634.qmail@cdy.org> Message-ID: <001601c5ecba$9bd4bd90$0264a8c0@demolish1> Peter Stuge wrote on Friday, November 18, 2005 7:20 PM > [...I'm pretty sure your guess is spot on. The possibility to disable > verification of IP-addresses vs. hostnames was likely removed > because, as I wrote, without that verification it is trivial for > anyone in control of a DNS-server serving PTR records to spoof their > connection as being from your allowed domain. Its wasn't a guess, I actually walked my way through the code using file diffs on old code to new code untill I found the relevant changes that effected my scenario. It was a one liner - the following code has been removed from file canohost.c if (!verify_reverse_mapping) return xstrdup(name); > > Before I could use the option: > > AllowUsers Auser@*.somedomain.com > > One has to admit that, whilst having reverse mappping turned off, > > this is far more secure than the option I'm now forced to use to > > achieve the same of: > > AllowUsers Auser@* > I'm afraid not. DNS is not a secure system and anything that trusts > DNS will be vulnerable to all problems that DNS is vulnerable to. I am not trying to be picky here but the point is I am able to use a lesser level of security and the openssh people haven't removed those options so why take away a level of security that is better than the worst case scenario. For example consider the options: 1) No AllowUsers option: Any user on my server can log in from any IP address and any domain, how secure is that? Open to all sorts of brute force attacks, yet this option is available. 2) Set the AllowUsers option with USER1 USER2 USER3... Only the listed users can log in and from any domain or any IP address. Hackers now have to guess which USERS to login as, not very secure but better than scenario 1). 3) Set the AllowUsers option with USER at DOMAIN and no reverse mapping checks. Only the listed users can log in and only from the listed domains. Hackers now have to guess the USERS and the DOMAIN - not particularly secure but better than scenarios 1) and 2). 4) Set the AllowUsers option to USER at DOMAIN with reverse mapping checks. Only the listed users can log in and only from the listed domains and a valid DNS A name record must exist. This is still not fool proof, especially for the dishonest DNS operator with a hacked DNS that doesn't propagate with other DNSs. The hacker still has to guess the USER name and the DOMAIN name and be the primary DNS for the system they are hacking... Not particularly likely, but not impossible - but a better security option than scenarios 1), 2) and 3). So once upon a time I could choose any of the above four listed security options, but now by removing the option VerifyReverseMapping, I am limited to scenarios 1), 2) and 4). (Please don't shoot me down and say well there are actually a lot of other options - I'm looking at one particular window of options here) You don't have to be a rocket scientist to figure out that options 1) and 2) are not as good as the option 3) which is now not possible - its a simply case of I should be able to choose which level of security I want, the more options the better, it shouldn't be forced upon me! One cannot use the argument we have taken this level of security away because it was not safe, when there are several other levels of security that are worse than the one taken away - end of story. I've put my points forward, I think they are valid and that's all I can do. I don't like having to patch things myself because it means I have to maintain packages specific for our needs, but if the powers to be don't see things in the same light as I do then I'll write a patch and be done with it - that's the beauty of open source software... If you don't like it fix it yourself and move on. I do appreciate the feed back, its nice to be able to debate things in an open environment, so thanks for all the feed back. Cheers Donald Fraser From dtucker at zip.com.au Sun Nov 20 14:01:14 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 20 Nov 2005 14:01:14 +1100 Subject: [PATCH] Solaris 10 and missing OpenSSL functions >128bit Message-ID: <20051120030114.GA27458@gate.dodgy.net.au> Hi all. Solaris 10's default libcrypto does not have support for AES 192 and 256 bit functions. The attached patch, against -current, and based partially on an earlier one by djm, will use OpenSSH's builtin rijndael code for all AES crypto functions and thus will allow it to build and function on Solaris 10 without the extra crypto packages (SUNWcry, SUNWcryr) or a locally built OpenSSL. Tested OK for me on Solaris 10/x86 but other testing appreciated (eg SPARC, AMD64). Note that it does not use the native OpenSSL's AES128 functions (even though that would be possible) and thus will not benefit from any optimizations or hardware support that may be present in it. This is deliberate, as using the builtin rijndael for all AES is a tested configuration whereas only using it for some is not. This can be changed later if it is proven safe. Also note that the regress tests will fail on the SSHv1 Blowfish test since that uses a 256 bit key, which is also broken in that OpenSSL. This will cause a runtime failure: $ ssh -1 -c blowfish localhost [...] cipher_init: EVP_CipherInit: set key failed for blowfish Index: cipher-aes.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/cipher-aes.c,v retrieving revision 1.4 diff -u -p -r1.4 cipher-aes.c --- cipher-aes.c 9 Dec 2003 08:05:43 -0000 1.4 +++ cipher-aes.c 20 Nov 2005 02:39:30 -0000 @@ -23,7 +23,11 @@ */ #include "includes.h" -#if OPENSSL_VERSION_NUMBER < 0x00907000L + +/* compatibility with old or broken OpenSSL versions */ +#include "openbsd-compat/openssl-compat.h" + +#ifdef USE_BUILTIN_RIJNDAEL RCSID("$OpenBSD: cipher-aes.c,v 1.2 2003/11/26 21:44:29 djm Exp $"); #include @@ -31,10 +35,6 @@ RCSID("$OpenBSD: cipher-aes.c,v 1.2 2003 #include "xmalloc.h" #include "log.h" -#if OPENSSL_VERSION_NUMBER < 0x00906000L -#define SSH_OLD_EVP -#endif - #define RIJNDAEL_BLOCKSIZE 16 struct ssh_rijndael_ctx { @@ -157,4 +157,4 @@ evp_rijndael(void) #endif return (&rijndal_cbc); } -#endif /* OPENSSL_VERSION_NUMBER */ +#endif /* USE_BUILTIN_RIJNDAEL */ Index: cipher-ctr.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/cipher-ctr.c,v retrieving revision 1.7 diff -u -p -r1.7 cipher-ctr.c --- cipher-ctr.c 17 Jul 2005 07:22:45 -0000 1.7 +++ cipher-ctr.c 20 Nov 2005 02:37:32 -0000 @@ -21,11 +21,10 @@ RCSID("$OpenBSD: cipher-ctr.c,v 1.6 2005 #include "log.h" #include "xmalloc.h" -#if OPENSSL_VERSION_NUMBER < 0x00906000L -#define SSH_OLD_EVP -#endif +/* compatibility with old or broken OpenSSL versions */ +#include "openbsd-compat/openssl-compat.h" -#if OPENSSL_VERSION_NUMBER < 0x00907000L +#ifdef USE_BUILTIN_RIJNDAEL #include "rijndael.h" #define AES_KEY rijndael_ctx #define AES_BLOCK_SIZE 16 Index: cipher.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/cipher.c,v retrieving revision 1.81 diff -u -p -r1.81 cipher.c --- cipher.c 17 Jul 2005 07:02:10 -0000 1.81 +++ cipher.c 20 Nov 2005 02:22:41 -0000 @@ -334,7 +334,7 @@ cipher_get_keyiv(CipherContext *cc, u_ch if ((u_int)evplen != len) fatal("%s: wrong iv length %d != %d", __func__, evplen, len); -#if OPENSSL_VERSION_NUMBER < 0x00907000L +#ifdef USE_BUILTIN_RIJNDAEL if (c->evptype == evp_rijndael) ssh_rijndael_iv(&cc->evp, 0, iv, len); else @@ -365,7 +365,7 @@ cipher_set_keyiv(CipherContext *cc, u_ch evplen = EVP_CIPHER_CTX_iv_length(&cc->evp); if (evplen == 0) return; -#if OPENSSL_VERSION_NUMBER < 0x00907000L +#ifdef USE_BUILTIN_RIJNDAEL if (c->evptype == evp_rijndael) ssh_rijndael_iv(&cc->evp, 1, iv, evplen); else Index: configure.ac =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/configure.ac,v retrieving revision 1.307 diff -u -p -r1.307 configure.ac --- configure.ac 12 Nov 2005 07:42:37 -0000 1.307 +++ configure.ac 20 Nov 2005 01:20:40 -0000 @@ -1745,6 +1745,24 @@ Also see contrib/findssl.sh for help ide ] ) +# Check for OpenSSL without EVP_aes_{192,256}_cbc +AC_MSG_CHECKING([whether OpenSSL has crippled AES support]) +AC_COMPILE_IFELSE( + [AC_LANG_SOURCE([[ +#include +#include +int main(void) { exit(EVP_aes_192_cbc() == NULL || EVP_aes_256_cbc() == NULL)} + ]])], + [ + AC_MSG_RESULT(no) + ], + [ + AC_MSG_RESULT(yes) + AC_DEFINE(OPENSSL_LOBOTOMISED_AES, 1, + [libcrypto is missing AES 192 and 256 bit functions]) + ] +) + # Some systems want crypt() from libcrypt, *not* the version in OpenSSL, # because the system crypt() is more featureful. if test "x$check_for_libcrypt_before" = "x1"; then Index: openbsd-compat/openssl-compat.h =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/openbsd-compat/openssl-compat.h,v retrieving revision 1.1 diff -u -p -r1.1 openssl-compat.h --- openbsd-compat/openssl-compat.h 9 Jun 2005 11:45:11 -0000 1.1 +++ openbsd-compat/openssl-compat.h 20 Nov 2005 02:30:01 -0000 @@ -24,7 +24,11 @@ # define EVP_CIPHER_CTX_get_app_data(e) ((e)->app_data) #endif -#if OPENSSL_VERSION_NUMBER < 0x00907000L +#if (OPENSSL_VERSION_NUMBER < 0x00907000L) || defined(OPENSSL_LOBOTOMISED_AES) +# define USE_BUILTIN_RIJNDAEL +#endif + +#ifdef USE_BUILTIN_RIJNDAEL # define EVP_aes_128_cbc evp_rijndael # define EVP_aes_192_cbc evp_rijndael # define EVP_aes_256_cbc evp_rijndael -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Sun Nov 20 14:15:16 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 20 Nov 2005 14:15:16 +1100 Subject: [PATCH] Optionally enable OpenSSL hardware support Message-ID: <20051120031516.GA28292@gate.dodgy.net.au> Hi all. While on the subject of the OpenSSL interface, this patch optionally enables OpenSSL's ENGINE support at build time. Apply to a snapshot, autoreconf and "./configure --with-ssl-engine". Testing (esp. with a real hardware engine) would be appreciated. Index: INSTALL =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/INSTALL,v retrieving revision 1.70 diff -u -p -r1.70 INSTALL --- INSTALL 24 Apr 2005 07:52:23 -0000 1.70 +++ INSTALL 1 Oct 2005 08:36:24 -0000 @@ -165,6 +165,8 @@ created. --with-ssl-dir=DIR allows you to specify where your OpenSSL libraries are installed. +--with-ssl-engine enables OpenSSL's (hardware) ENGINE support + --with-4in6 Check for IPv4 in IPv6 mapped addresses and convert them to real (AF_INET) IPv4 addresses. Works around some quirks on Linux. Index: configure.ac =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/configure.ac,v retrieving revision 1.307 diff -u -p -r1.307 configure.ac --- configure.ac 12 Nov 2005 07:42:37 -0000 1.307 +++ configure.ac 20 Nov 2005 03:06:37 -0000 @@ -1745,6 +1745,24 @@ Also see contrib/findssl.sh for help ide ] ) +AC_ARG_WITH(ssl-engine, + [ --with-ssl-engine Enable OpenSSL (hardware) ENGINE support ], + [ if test "x$withval" != "xno" ; then + AC_MSG_CHECKING(for OpenSSL ENGINE support) + AC_TRY_COMPILE( + [ #include ], + [ +int main(void){ENGINE_load_builtin_engines();ENGINE_register_all_complete();} + ], + [ AC_MSG_RESULT(yes) + AC_DEFINE(USE_OPENSSL_ENGINE, 1, + [Enable OpenSSL engine support]) + ], + [ AC_MSG_ERROR(OpenSSL ENGINE support not found)] + ) + fi ] +) + # Some systems want crypt() from libcrypt, *not* the version in OpenSSL, # because the system crypt() is more featureful. if test "x$check_for_libcrypt_before" = "x1"; then Index: openbsd-compat/openssl-compat.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/openbsd-compat/openssl-compat.c,v retrieving revision 1.2 diff -u -p -r1.2 openssl-compat.c --- openbsd-compat/openssl-compat.c 17 Jun 2005 11:15:21 -0000 1.2 +++ openbsd-compat/openssl-compat.c 1 Oct 2005 08:58:50 -0000 @@ -18,7 +18,11 @@ #include "includes.h" -#define SSH_DONT_REDEF_EVP +#ifdef USE_OPENSSL_ENGINE +# include +#endif + +#define SSH_DONT_OVERLOAD_OPENSSL_FUNCS #include "openssl-compat.h" #ifdef SSH_OLD_EVP @@ -44,3 +48,15 @@ ssh_EVP_CIPHER_CTX_cleanup(EVP_CIPHER_CT return 1; } #endif + +void +ssh_SSLeay_add_all_algorithms(void) +{ + SSLeay_add_all_algorithms(); + +#ifdef USE_OPENSSL_ENGINE + /* Enable use of crypto hardware */ + ENGINE_load_builtin_engines(); + ENGINE_register_all_complete(); +#endif +} Index: openbsd-compat/openssl-compat.h =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/openbsd-compat/openssl-compat.h,v retrieving revision 1.2 diff -u -p -r1.2 openssl-compat.h --- openbsd-compat/openssl-compat.h 20 Nov 2005 03:10:00 -0000 1.2 +++ openbsd-compat/openssl-compat.h 20 Nov 2005 03:10:30 -0000 @@ -52,7 +52,7 @@ extern const EVP_CIPHER *evp_acss(void); */ #ifdef SSH_OLD_EVP -# ifndef SSH_DONT_REDEF_EVP +# ifndef SSH_DONT_OVERLOAD_OPENSSL_FUNCS # ifdef EVP_Cipher # undef EVP_Cipher @@ -68,3 +68,8 @@ int ssh_EVP_CipherInit(EVP_CIPHER_CTX *, int ssh_EVP_Cipher(EVP_CIPHER_CTX *, char *, char *, int); int ssh_EVP_CIPHER_CTX_cleanup(EVP_CIPHER_CTX *); #endif + +#ifndef SSH_DONT_OVERLOAD_OPENSSL_FUNCS +# define SSLeay_add_all_algorithms() ssh_SSLeay_add_all_algorithms() +#endif +void ssh_SSLeay_add_all_algorithms(void); -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From andreas.gaupmann at gmx.net Mon Nov 21 21:06:22 2005 From: andreas.gaupmann at gmx.net (Andreas Gaupmann) Date: Mon, 21 Nov 2005 11:06:22 +0100 (MET) Subject: SSH lib for Win32...? References: <191001c5ec6a$84122f80$6501a8c0@toshibauser> Message-ID: <1719.1132567582@www44.gmx.net> Hello! There is no such thing like a OpenSSH library. Consider using stunnel instead of writing your on tunneling software. It is also available for Win32 at http://www.stunnel.org/ Cheers Andreas > --- Urspr?ngliche Nachricht --- > Von: "Robert Bates \(Cobra Powersports\)" > An: > Betreff: SSH lib for Win32...? > Datum: Fri, 18 Nov 2005 13:04:27 -0500 > > Hi there! > > I'm researching a project for my company that would involve a proprietary > SSH tunnel client running on Win32. I was wondering if OpenSSH had a > portable library component that I could leverage to manage the connection > and tunneling functionality without any interface components...? > > Thanks in advance for any help or direction you can provide! > > ========== > Robert Bates > Cobra Powersports * http://www.cobrasales.com > rob at cobrasales.com * 713-866-6262 x109 > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From rinsan at lysator.liu.se Mon Nov 21 21:15:37 2005 From: rinsan at lysator.liu.se (Claes Leufven) Date: Mon, 21 Nov 2005 11:15:37 +0100 Subject: "User child pid" logging Message-ID: <878xvitigm.fsf@rei.outherlimits.org> Hi! It would be easier to trace a connection in the logs if sshd reported the change of pid with LogLevel set to verbose instead of debug2. Is it possible to have it changed? Regards Claes Leufv?n Here is a patch for it: --- sshd.c_orig 2005-11-21 10:51:08.000000000 +0100 +++ sshd.c 2005-11-21 10:51:11.000000000 +0100 @@ -652,7 +652,7 @@ if (pmonitor->m_pid == -1) fatal("fork of unprivileged child failed"); else if (pmonitor->m_pid != 0) { - debug2("User child is on pid %ld", (long)pmonitor->m_pid); + verbose("User child is on pid %ld", (long)pmonitor->m_pid); close(pmonitor->m_recvfd); buffer_clear(&loginmsg); monitor_child_postauth(pmonitor); -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 185 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20051121/168a8d14/attachment.bin From shaw at vranix.com Tue Nov 22 05:12:56 2005 From: shaw at vranix.com (Shaw Vrana) Date: Mon, 21 Nov 2005 10:12:56 -0800 Subject: [PATCH] 64 bit clean compilation patches Message-ID: <43820E28.6020908@vranix.com> Hello All, Attached is a patch against the portable openssh sources found at openssh at anoncvs.at.openbsd.org:/cvs. The majority of the size of the patch comes from changes to the build system to supply the required format specifications if they are not provided by the OS. These patches remove the following warnings found during a 64-bit compile: hostfile.c: In function `extract_salt': hostfile.c:92: warning: unsigned int format, different type arg (arg 2) progressmeter.c: In function `format_rate': progressmeter.c:91: warning: long long int format, off_t arg (arg 4) progressmeter.c:91: warning: long long int format, off_t arg (arg 5) progressmeter.c:91: warning: long long int format, off_t arg (arg 4) progressmeter.c:91: warning: long long int format, off_t arg (arg 5) progressmeter.c: In function `format_size': progressmeter.c:104: warning: long long int format, off_t arg (arg 4) progressmeter.c:104: warning: long long int format, off_t arg (arg 4) loginrec.c: In function `lastlog_get_entry': loginrec.c:1592: warning: int format, different type arg (arg 4) loginrec.c: In function `record_failed_login': loginrec.c:1655: warning: passing arg 3 of `getpeername' from incompatible pointer typescp.c: loginrec.c:1656: warning: passing arg 2 of `ipv64_normalise_mapped' from incompatible pointer type In function `source': scp.c:566: warning: long long int format, __off_t arg (arg 5) scp.c:566: warning: long long int format, __off_t arg (arg 5) These patches were tested on a 32-bit GNU/Linux machine with inttypes.h, 32-bit FreeBSD without inttypes.h, and a 64-bit GNU/Linux machine with inttypes.h. Please apply! Shaw -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diff.txt Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20051121/7d9d2c65/attachment.txt From dan at D00M.lightwave.net.ru Tue Nov 22 05:56:12 2005 From: dan at D00M.lightwave.net.ru (Dan Yefimov) Date: Mon, 21 Nov 2005 21:56:12 +0300 (MSK) Subject: [PATCH] 64 bit clean compilation patches In-Reply-To: <43820E28.6020908@vranix.com> Message-ID: On Mon, 21 Nov 2005, Shaw Vrana wrote: > Hello All, > > Attached is a patch against the portable openssh sources found at > openssh at anoncvs.at.openbsd.org:/cvs. The majority of the size of the > patch comes from changes to the build system to supply the required > format specifications if they are not provided by the OS. These patches > remove the following warnings found during a 64-bit compile: > > hostfile.c: In function `extract_salt': > hostfile.c:92: warning: unsigned int format, different type arg (arg 2) > progressmeter.c: In function `format_rate': > progressmeter.c:91: warning: long long int format, off_t arg (arg 4) > progressmeter.c:91: warning: long long int format, off_t arg (arg 5) > progressmeter.c:91: warning: long long int format, off_t arg (arg 4) > progressmeter.c:91: warning: long long int format, off_t arg (arg 5) > progressmeter.c: In function `format_size': > progressmeter.c:104: warning: long long int format, off_t arg (arg 4) > progressmeter.c:104: warning: long long int format, off_t arg (arg 4) > loginrec.c: In function `lastlog_get_entry': > loginrec.c:1592: warning: int format, different type arg (arg 4) > loginrec.c: In function `record_failed_login': > loginrec.c:1655: warning: passing arg 3 of `getpeername' from > incompatible pointer typescp.c: > loginrec.c:1656: warning: passing arg 2 of `ipv64_normalise_mapped' from > incompatible pointer type > In function `source': > scp.c:566: warning: long long int format, __off_t arg (arg 5) > scp.c:566: warning: long long int format, __off_t arg (arg 5) > > These patches were tested on a 32-bit GNU/Linux machine with inttypes.h, > 32-bit FreeBSD without inttypes.h, and a 64-bit GNU/Linux machine with > inttypes.h. > Wouldn't it be much simpler to cast printf() arguments in question to appropriate type or correct appropriate printf() format string modifiers instead of doing such a big change? For example, in loginrec.c you could either cast sizeof(last) result to int instead of int32_t or simply change corresponding %d modifier to %u, as sizeof() result is of type unsigned int; in progressmeter.c you could cast results of corresponding expressions to long long type. The same applies to scp.c and sftp-server.c too. -- Sincerely Your, Dan. From jblaine at mitre.org Tue Nov 22 07:20:54 2005 From: jblaine at mitre.org (Jeff Blaine) Date: Mon, 21 Nov 2005 15:20:54 -0500 Subject: --with-zlib vs. --with-ssl-dir Message-ID: <43822C26.9080507@mitre.org> Unnecessarily different, right? Why not pick one form or the other consistently? --with-something-dir (makes much more sense) or --with-something (looks like a package enabler) From shaw at vranix.com Tue Nov 22 08:04:19 2005 From: shaw at vranix.com (Shaw Vrana) Date: Mon, 21 Nov 2005 13:04:19 -0800 Subject: [PATCH] 64 bit clean compilation patches In-Reply-To: References: Message-ID: <43823653.3050004@vranix.com> > Wouldn't it be much simpler to cast printf() arguments in question to > appropriate type or correct appropriate printf() format string modifiers > instead of doing such a big change? For example, in loginrec.c you could either > cast sizeof(last) result to int instead of int32_t or simply change > corresponding %d modifier to %u, as sizeof() result is of type unsigned int; in > progressmeter.c you could cast results of corresponding expressions to > long long type. The same applies to scp.c and sftp-server.c too. How's this? And I also removed my previous change to loginrec.c and applied Darren's patch that he sent in an earlier exchange about these warnings. Thanks, Shaw -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diff.txt Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20051121/a96636a8/attachment.txt From dtucker at zip.com.au Tue Nov 22 20:09:58 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 22 Nov 2005 20:09:58 +1100 Subject: [PATCH] 64 bit clean compilation patches In-Reply-To: <43823653.3050004@vranix.com> References: <43823653.3050004@vranix.com> Message-ID: <20051122090957.GA13639@gate.dodgy.net.au> On Mon, Nov 21, 2005 at 01:04:19PM -0800, Shaw Vrana wrote: > How's this? > > And I also removed my previous change to loginrec.c and applied Darren's > patch that he sent in an earlier exchange about these warnings. > - debug2("extract_salt: expected salt len %u, got %u", > - salt_len, ret); > + debug2("extract_salt: expected salt len %d, got %d", > + SHA_DIGEST_LENGTH, ret); Applied. > - __func__, LASTLOG_FILE, sizeof(last), ret); > + __func__, LASTLOG_FILE, (int)sizeof(last), ret); [...] > - size_t fromlen = sizeof(from); > + socklen_t fromlen = sizeof(from); Applied. [...] > snprintf(buf, size, "%4lld%c%s", > - (int64_t) bytes, > + (long long) bytes, These ones I haven't applied yet, although I'm inclined to. These would actually bring us closer to the OpenBSD version, but I'm wondering if there's any reason why it is the way it is? djm? [...] > TRACE("read id %u handle %d off %llu len %d", id, handle, > - (u_int64_t)off, len); > + (long long)off, len); This should be "unsigned long long", but other than that the comment above also applies. Thanks. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Tue Nov 22 21:31:55 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 22 Nov 2005 21:31:55 +1100 Subject: --with-zlib vs. --with-ssl-dir In-Reply-To: <43822C26.9080507@mitre.org> References: <43822C26.9080507@mitre.org> Message-ID: <20051122103155.GA15340@gate.dodgy.net.au> On Mon, Nov 21, 2005 at 03:20:54PM -0500, Jeff Blaine wrote: > Unnecessarily different, right? Why not pick one form or > the other consistently? > > --with-something-dir (makes much more sense) > or > --with-something (looks like a package enabler) I think the original intent was that the latter would be optional. Most of the existing options of that form (eg --with-kerberos5, --with-pam and so on) are. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From djm at mindrot.org Tue Nov 22 21:38:43 2005 From: djm at mindrot.org (Damien Miller) Date: Tue, 22 Nov 2005 21:38:43 +1100 Subject: --with-zlib vs. --with-ssl-dir In-Reply-To: <20051122103155.GA15340@gate.dodgy.net.au> References: <43822C26.9080507@mitre.org> <20051122103155.GA15340@gate.dodgy.net.au> Message-ID: <20051122213843.5783620f.djm@mindrot.org> On Tue, 22 Nov 2005 21:31:55 +1100 Darren Tucker wrote: > On Mon, Nov 21, 2005 at 03:20:54PM -0500, Jeff Blaine wrote: > > Unnecessarily different, right? Why not pick one form or > > the other consistently? > > > > --with-something-dir (makes much more sense) > > or > > --with-something (looks like a package enabler) > > I think the original intent was that the latter would be optional. > Most of the existing options of that form (eg --with-kerberos5, > --with-pam and so on) are. Also OpenSSL has a history of installing itself in a particular directory (e.g. /usr/local/openssl) as opposed to under a prefix, such as /usr/local/{lib,include}. That was the original intent behind the -with-ssl-dir option IIRC. -d From dtucker at zip.com.au Tue Nov 22 22:27:14 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 22 Nov 2005 22:27:14 +1100 Subject: [PATCH] Use krb5-config if avaialable for Kerberos parameters In-Reply-To: References: <20051112083428.GA18277@gate.dodgy.net.au> <20051112085527.GA18870@gate.dodgy.net.au> Message-ID: <20051122112714.GA4365@gate.dodgy.net.au> On Mon, Nov 14, 2005 at 09:38:00AM +1000, David Leonard wrote: > Well, that patch won't work with our krb5-config You'll get back an > empty string, since --path is not understood. :( How about this one? It doesn't want to know KRB5ROOT if a working krb5-config is found. Index: configure.ac =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/configure.ac,v retrieving revision 1.307 diff -u -p -r1.307 configure.ac --- configure.ac 12 Nov 2005 07:42:37 -0000 1.307 +++ configure.ac 22 Nov 2005 11:01:56 -0000 @@ -2812,19 +2812,23 @@ AC_ARG_WITH(kerberos5, [ --with-kerberos5=PATH Enable Kerberos 5 support], [ if test "x$withval" != "xno" ; then if test "x$withval" = "xyes" ; then - KRB5ROOT="/usr/local" + # Check for a krb5-config in the path, if found use it + AC_PATH_PROG(KRB5CONF, krb5-config) + if test ! -x "$KRB5CONF" ; then + KRB5ROOT="/usr/local" + KRB5CONF="/usr/local/bin/krb5-config" + fi else - KRB5ROOT=${withval} + KRB5ROOT="${withval}" + KRB5CONF="${withval}/bin/krb5-config" fi AC_DEFINE(KRB5, 1, [Define if you want Kerberos 5 support]) KRB5_MSG="yes" - AC_MSG_CHECKING(for krb5-config) - if test -x $KRB5ROOT/bin/krb5-config ; then - KRB5CONF=$KRB5ROOT/bin/krb5-config - AC_MSG_RESULT($KRB5CONF) - + AC_MSG_CHECKING(if $KRB5CONF is usable) + if test -x "$KRB5CONF" ; then + AC_MSG_RESULT(yes) AC_MSG_CHECKING(for gssapi support) if $KRB5CONF | grep gssapi >/dev/null ; then AC_MSG_RESULT(yes) -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From jblaine at mitre.org Wed Nov 23 02:12:09 2005 From: jblaine at mitre.org (Jeff Blaine) Date: Tue, 22 Nov 2005 10:12:09 -0500 Subject: --with-zlib vs. --with-ssl-dir In-Reply-To: <20051122213843.5783620f.djm@mindrot.org> References: <43822C26.9080507@mitre.org> <20051122103155.GA15340@gate.dodgy.net.au> <20051122213843.5783620f.djm@mindrot.org> Message-ID: <43833549.4050608@mitre.org> Both comments understood. Do they change anything though? It still seems off to me. I have to think there's a better way to denote "this is optional" :) Removing '-dir' from an argument that makes sense to have it, to make it like the other arguments that are optional, seems awful obtuse :) But if everyone else is happy with it, I'm sure I'll live. Damien Miller wrote: > On Tue, 22 Nov 2005 21:31:55 +1100 > Darren Tucker wrote: > > >>On Mon, Nov 21, 2005 at 03:20:54PM -0500, Jeff Blaine wrote: >> >>>Unnecessarily different, right? Why not pick one form or >>>the other consistently? >>> >>> --with-something-dir (makes much more sense) >>>or >>> --with-something (looks like a package enabler) >> >>I think the original intent was that the latter would be optional. >>Most of the existing options of that form (eg --with-kerberos5, >>--with-pam and so on) are. > > > Also OpenSSL has a history of installing itself in a particular > directory (e.g. /usr/local/openssl) as opposed to under a > prefix, such as /usr/local/{lib,include}. > > That was the original intent behind the -with-ssl-dir option IIRC. > > -d > From shaw at vranix.com Wed Nov 23 05:34:52 2005 From: shaw at vranix.com (Shaw Vrana) Date: Tue, 22 Nov 2005 10:34:52 -0800 Subject: [PATCH] 64 bit clean compilation patches In-Reply-To: <20051122090957.GA13639@gate.dodgy.net.au> References: <43823653.3050004@vranix.com> <20051122090957.GA13639@gate.dodgy.net.au> Message-ID: <438364CC.1050302@vranix.com> Also troublesome are the following 64-bit related compilation warnings in scp.c : scp.c:589: warning: comparison between signed and unsigned scp.c:596: warning: comparison between signed and unsigned The stat structure likes the off_t, otherwise size_t is used. I'm not sure what to do with these. Any suggestions for a portable change here? Thanks again, Shaw -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: open.diff.txt Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20051122/ae457021/attachment.txt From openssh at roumenpetrov.info Wed Nov 23 06:57:40 2005 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Tue, 22 Nov 2005 21:57:40 +0200 Subject: --with-zlib vs. --with-ssl-dir In-Reply-To: <43833549.4050608@mitre.org> References: <43822C26.9080507@mitre.org> <20051122103155.GA15340@gate.dodgy.net.au> <20051122213843.5783620f.djm@mindrot.org> <43833549.4050608@mitre.org> Message-ID: <43837834.10405@roumenpetrov.info> The common (standard) use for optional packages is: --with-PACKAGE[=ARG] use PACKAGE [ARG=yes] This is "two state" argument: -enable: --with-PACKAGE or --with-PACKAGE=yes -disable: --with-PACKAGE=no or --without-PACKAGE To minimize arguments many projects use "three state" --with-PACKAGE[=PATH] : -enable and search in default locations: --with-PACKAGE or --with-PACKAGE=yes -enable and search in specified prefix and optionaly in default locations: --with-PACKAGE=path -disable: --with-PACKAGE=no or --without-PACKAGE Without "three state" argument configure script sould use two arguments: --with-PACKAGE[=ARG] or --enable-FEATURE , to enable/disable package/feature and one more --with-PACKAGE-dir=PATH or --PACKAGE-dir=PATH or ... , to specify location. I prefer "three state" arguments. Jeff Blaine wrote: > Both comments understood. Do they change anything > though? It still seems off to me. I have to think > there's a better way to denote "this is optional" :) > > Removing '-dir' from an argument that makes sense to > have it, to make it like the other arguments that are > optional, seems awful obtuse :) > > But if everyone else is happy with it, I'm sure I'll > live. > > Damien Miller wrote: > >>On Tue, 22 Nov 2005 21:31:55 +1100 >>Darren Tucker wrote: >> >> >> >>>On Mon, Nov 21, 2005 at 03:20:54PM -0500, Jeff Blaine wrote: >>> >>> >>>>Unnecessarily different, right? Why not pick one form or >>>>the other consistently? >>>> >>>> --with-something-dir (makes much more sense) >>>>or >>>> --with-something (looks like a package enabler) >>> >>>I think the original intent was that the latter would be optional. >>>Most of the existing options of that form (eg --with-kerberos5, >>>--with-pam and so on) are. >> >> >>Also OpenSSL has a history of installing itself in a particular >>directory (e.g. /usr/local/openssl) as opposed to under a >>prefix, such as /usr/local/{lib,include}. >> >>That was the original intent behind the -with-ssl-dir option IIRC. >> >>-d From Jason.C.Burns at wellsfargo.com Wed Nov 23 07:23:06 2005 From: Jason.C.Burns at wellsfargo.com (Jason.C.Burns at wellsfargo.com) Date: Tue, 22 Nov 2005 14:23:06 -0600 Subject: 4.2 and the 'last' command Message-ID: > Jason.C.Burns at wellsfargo.com wrote: > > My question: I can't find in the source where 'last' is explicitly > > called, so is there an API call that was added between > these versions > > that would refer the system to 'last'? > > Depends. What platform are you running, and which build and > run-time options have you enabled? > > AFAIK sshd doesn't exec "last" itself, although it's possible > that something it calls does under the covers. Thanks for the reply Darren. The main system I can see the problem is HP-UX, 11.00 and 11i. The build options are: --with-pam --disable-suid-ssh --without-rsh --with-ssl-dir= --with-kerberos5= --with-tcp-wrappers= --with-zlib= --with-default-path= --with-superuser-path= --without-privsep-user --without-privsep-path --prefix= --sysconfdir= --with-libs="-L/lib -L/usr/lib -L/usr/local/lib" --with-rand-helper --with-random=/dev/urandom --with-ldflags=-ldld Run time: ssh: ForwardX11 yes GSSAPIDelegateCredentials yes GSSAPIAuthentication yes sshd: ChallengeResponseAuthentication yes KerberosAuthentication no GSSAPIAuthentication yes UsePAM yes X11Forwarding yes UsePrivilegeSeparation no MaxStartups 30 Subsystem sftp /usr/libexec/sftp-server I agree. From what I've looked at, I can't see 'last' being called explicitly. Using process monitoring tools, I don't even see last being called on Linux and Solaris systems, but it could be running too fast to catch. I'm still looking to see anything where sshd asks the system for the last login information and last is implicitly called, but any information you might be able to provide would be much appreciated! Jason From andreas.gaupmann at fh-hagenberg.at Wed Nov 23 07:49:40 2005 From: andreas.gaupmann at fh-hagenberg.at (Andreas Gaupmann) Date: Tue, 22 Nov 2005 21:49:40 +0100 Subject: [PATCH] Introducing Zero-Knowledge user authentication Message-ID: <200511222149.46329.andreas.gaupmann@fh-hagenberg.at> Hello! With this email we release an extension to OpenSSH that was initially developed as project for our studies at the Univerity of Applied Sciences in Hagenberg. First we would like to describe the purpose of using Zero-Knowledge (ZK) for user authentication. Traditional authentication methods like challenge-response with passwords or public keys leak information about the credentials of a user (prover) to the verifying or any other party that can access the exchanged messages. Thus, with every finished authentication process the adversary has a greater chance of successfully purporting to third parties to be the prover. ZK avoids this drawback. The theory is more than twenty years old and is accepted by the cryptographic community. We have chosen the ZK protocol of Ohta-Okamoto for implementation. This protocol is not encumbered by any patents. We have set up a website[1] that gives a short introduction on ZK and on how this new user authentication method can be enabled and used. Patches for the OpenBSD and portable versions can be downloaded from our website. They are not attached to this email because of their size. We have developed the ZK extension for the 4.0/4.0p1 releases of OpenSSH and can currently only offer patches for these releases. We are aware that this is not ideal. Depending on the feedback of the OpenSSH community, we would also release patches for the newest version and maintain the patch. Now some notes on the actual implementation. We have used the existing user authentications as templates for incorporating the ZK protocol into OpenSSH. Like pubkey authentication the user has a key pair. Subsequently, we have adjusted the ssh-keygen for generating keys of type OO-ZK that can be used in the usual way as identity files and in the authorized keys files. Currently, the keygen cannot be used for changing the passphrase or other metadata in the key file. Please have a look at our patch and comment on it. We are interested in your feedback. Regards Andreas Gaupmann Christian Schausberger Ulrich Zehl [1] http://zk-ssh.cms.ac/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20051122/e8792bd5/attachment.bin From dtucker at zip.com.au Wed Nov 23 11:51:00 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 23 Nov 2005 11:51:00 +1100 Subject: 4.2 and the 'last' command In-Reply-To: References: Message-ID: <20051123005100.GA4513@gate.dodgy.net.au> On Tue, Nov 22, 2005 at 02:23:06PM -0600, Jason.C.Burns at wellsfargo.com wrote: > The main system I can see the problem is HP-UX, 11.00 and 11i. > > The build options are: > --with-pam I'll bet PAM calls "last" to generate its "last logged in at" messages. Do you see "last" running if you run sshd with UsePAM set to "no"? Do other login methods (eg telnetd) do the same thing with last? How often do you clear your wtmp files? -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From djm at mindrot.org Thu Nov 24 14:27:33 2005 From: djm at mindrot.org (Damien Miller) Date: Thu, 24 Nov 2005 14:27:33 +1100 (EST) Subject: test, please ignore Message-ID: test, please ignore From dtucker at zip.com.au Thu Nov 24 13:35:34 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 24 Nov 2005 13:35:34 +1100 Subject: 4.2 and the 'last' command In-Reply-To: References: Message-ID: <20051124023534.GA9292@gate.dodgy.net.au> On Wed, Nov 23, 2005 at 05:23:46PM -0600, Jason.C.Burns at wellsfargo.com wrote: > > I'll bet PAM calls "last" to generate its "last logged in at" > > messages. > > Do you see "last" running if you run sshd with UsePAM set to "no"? > > Yes. Running sshd without GSSAPI, PAM, or Login, last is still called. > > This is the debug output from sshd: > debug3: send_rexec_state: entering fd = 7 config len 379 > debug3: ssh_msg_send: type 0 > debug3: send_rexec_state: done > debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7 > > debug1: inetd sockets after dupping: 3, 3 > Connection from xx.xx.xx.xx port 36540 Ah, ok. That makes sense now. It's the entropy gatherer (ssh-random-helper) that's running "last", not sshd, and it's being run when sshd reexecs itself for each connection. ssh-random-helper will attempt to kill off programs that run more than a couple of seconds, though it uses SIGTERM so a process can ignore it. I can see 4 options for resolving this. 1) remove the "last" calls from ssh_prngd_cmds. 2) install prngd, which will obviate the need for sshd to run ssh-random-helper. 3) run sshd with the (undocumented) -r option to disable reexec. 4) apply the following patch, which will be in OpenSSH 4.3. The latter 2 will still mean "last" will probably be run at startup of both sshd and ssh but not when sshd accepts a new connection. And now the patch, against 4.2p1: - (dtucker) [entropy.c entropy.h sshd.c] Pass RNG seed to the reexec'ed process when sshd relies on ssh-random-helper. Should result in faster logins on systems without a real random device or prngd. ok djm@ Index: entropy.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/entropy.c,v retrieving revision 1.49 diff -u -p -r1.49 entropy.c --- entropy.c 17 Jul 2005 07:26:44 -0000 1.49 +++ entropy.c 24 Nov 2005 02:15:59 -0000 @@ -26,6 +26,7 @@ #include #include +#include #include "ssh.h" #include "misc.h" @@ -33,6 +34,8 @@ #include "atomicio.h" #include "pathnames.h" #include "log.h" +#include "buffer.h" +#include "bufaux.h" /* * Portable OpenSSH PRNG seeding: @@ -152,3 +155,30 @@ init_rng(void) #endif } +#ifndef OPENSSL_PRNG_ONLY +void +rexec_send_rng_seed(Buffer *m) +{ + u_char buf[RANDOM_SEED_SIZE]; + + if (RAND_bytes(buf, sizeof(buf)) <= 0) { + error("Couldn't obtain random bytes (error %ld)", + ERR_get_error()); + buffer_put_string(m, "", 0); + } else + buffer_put_string(m, buf, sizeof(buf)); +} + +void +rexec_recv_rng_seed(Buffer *m) +{ + char *buf; + u_int len; + + buf = buffer_get_string_ret(m, &len); + if (buf != NULL) { + debug3("rexec_recv_rng_seed: seeding rng with %u bytes", len); + RAND_add(buf, len, len); + } +} +#endif Index: entropy.h =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/entropy.h,v retrieving revision 1.4 diff -u -p -r1.4 entropy.h --- entropy.h 9 Feb 2001 01:55:36 -0000 1.4 +++ entropy.h 24 Nov 2005 02:15:59 -0000 @@ -22,12 +22,17 @@ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ -/* $Id: entropy.h,v 1.4 2001/02/09 01:55:36 djm Exp $ */ +/* $Id: entropy.h,v 1.5 2005/09/27 12:46:32 dtucker Exp $ */ #ifndef _RANDOMS_H #define _RANDOMS_H +#include "buffer.h" + void seed_rng(void); void init_rng(void); +void rexec_send_rng_seed(Buffer *); +void rexec_recv_rng_seed(Buffer *); + #endif /* _RANDOMS_H */ Index: sshd.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/sshd.c,v retrieving revision 1.313 diff -u -p -r1.313 sshd.c --- sshd.c 26 Jul 2005 11:54:56 -0000 1.313 +++ sshd.c 24 Nov 2005 02:15:59 -0000 @@ -800,6 +800,7 @@ send_rexec_state(int fd, Buffer *conf) * bignum iqmp " * bignum p " * bignum q " + * string rngseed (only if OpenSSL is not self-seeded) */ buffer_init(&m); buffer_put_cstring(&m, buffer_ptr(conf)); @@ -816,6 +817,10 @@ send_rexec_state(int fd, Buffer *conf) } else buffer_put_int(&m, 0); +#ifndef OPENSSL_PRNG_ONLY + rexec_send_rng_seed(&m); +#endif + if (ssh_msg_send(fd, 0, &m) == -1) fatal("%s: ssh_msg_send failed", __func__); @@ -858,6 +863,11 @@ recv_rexec_state(int fd, Buffer *conf) rsa_generate_additional_parameters( sensitive_data.server_key->rsa); } + +#ifndef OPENSSL_PRNG_ONLY + rexec_recv_rng_seed(&m); +#endif + buffer_free(&m); debug3("%s: done", __func__); @@ -1051,8 +1061,6 @@ main(int ac, char **av) drop_cray_privs(); #endif - seed_rng(); - sensitive_data.server_key = NULL; sensitive_data.ssh1_host_key = NULL; sensitive_data.have_ssh1_key = 0; @@ -1071,6 +1079,8 @@ main(int ac, char **av) if (!rexec_flag) buffer_free(&cfg); + seed_rng(); + /* Fill in default values for those options not explicitly set. */ fill_default_server_options(&options); -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From alon.barlev at gmail.com Thu Nov 24 19:06:53 2005 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Thu, 24 Nov 2005 10:06:53 +0200 Subject: pkcs11 patch for openssh In-Reply-To: <4384EDE4.304@gmx.de> References: <4384BF64.3040406@gmx.de> <4384D1C4.8090808@gmail.com> <4384E58F.10701@gmx.de> <4384E899.9080009@gmail.com> <4384EDE4.304@gmx.de> Message-ID: <4385749D.3080803@gmail.com> Cornelius Koelbel wrote: > Hello again, > > it absolutely great. It works. > I realized that the cat'ing to the authorized_keys didn't contain a > neccessary line break, so two public keys where concatenated togeather. > > Thats cool. > > When do you think this patch will be merged into the openssh tree? This is a good question. I cannot answer that. I don't control OpenSSH. Best Regards, Alon Bar-Lev. From djm at mindrot.org Thu Nov 24 20:09:06 2005 From: djm at mindrot.org (Damien Miller) Date: Thu, 24 Nov 2005 20:09:06 +1100 Subject: Call for release testing Message-ID: <20051124200906.18ac8906.djm@mindrot.org> Hi All, We are planning on doing one of our regular releases (4.3/4.3p1) in around a week. This is a bugfix release, but a few of the portability bits have changed, so we would again appreciate testing on as many systems as possible. Some of the bugs fixed and internal improvements are: * X forwarding won't start when a command is executed in background (Bug #1086) * Change ssh-keygen to generate a RSA2 key when invoked without arguments (Bug #1064) * Fix timing variance for valid vs. invalid accounts when attempting Kerberos authentication (Bug #975) * Cleanup wtmp files on SIGTERM when not using privsep (Bug #1029) * X11 applications can sometimes not connect to 127.0.0.1:60xx by setting SO_REUSEADDR on X11 listeners (Bug #1076) * Xauth list invocation has bogus "." argument (Bug #1082) * Man page fixes: #1037 - Man page for -L and -R should mention -g. #1077 - Descriptions for "ssh -D" and DynamicForward should mention they can specify "bind_address" optionally. #1088 - Incorrect descriptions in ssh_config man page for ControlMaster=no. * Lots of cleanups, including fixes to memory leaks on error paths (Bugs #1109, #1110, #1111 and more) and possible crashes (bug #1092) * Portable OpenSSH-specific fixes: - PAM message reporting fixes: #1045 - Missing option for ignoring the /etc/nologin file #1087 - Show PAM password expiry message from LDAP on login #1028 - Forward final non-query conversations to client - Portability-related fixes: #1097 - Cross-compile fixes. #989 - Fix multiplexing regress test on Solairs #1096 - ssh-keygen broken on HPUX. #1098 - $MAIL being set incorrectly for HPUX server login. #1104 - Compile error on Tru64 Unix 4.0f #1106 - Updated .spec file and startup for SuSE. More detail may be found in the ChangeLog in the portable OpenSSH tarballs. The OpenBSD version is available in CVS HEAD: http://www.openbsd.org/anoncvs.html Portable snapshots are available at: ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/snapshot/ or one of its mirrors listed at http://www.openssh.com/portable.html#ftp Running the regression tests supplied with Portable does not require installation and is a simply: $ ./configure && make tests Testing on suitable non-production systems is also appreciated. Please send reports of success or failure to openssh-unix-dev at mindrot.org. Thanks, Damien Miller From johane at lysator.liu.se Thu Nov 24 20:26:09 2005 From: johane at lysator.liu.se (Johan Gill) Date: Thu, 24 Nov 2005 10:26:09 +0100 Subject: [PATCH] Fix typos and an error Message-ID: <20051124092609.GA18902@zeratul.lysator.liu.se> This patch fixes two typos and one case of wrong parameter ordering in configure.ac. Cheers Johan Gill, johane at lysator.liu.se -------------- next part -------------- Index: configure.ac =================================================================== RCS file: /cvs/openssh/configure.ac,v retrieving revision 1.307 diff -u -r1.307 configure.ac --- configure.ac 12 Nov 2005 07:42:37 -0000 1.307 +++ configure.ac 24 Nov 2005 09:00:16 -0000 @@ -410,8 +410,8 @@ *-sni-sysv*) # /usr/ucblib MUST NOT be searched on ReliantUNIX AC_CHECK_LIB(dl, dlsym, ,) - # -lresolv needs to be at then end of LIBS or DNS lookups break - AC_CHECK_LIB(res_query, resolv, [ LIBS="$LIBS -lresolv" ]) + # -lresolv needs to be at the end of LIBS or DNS lookups break + AC_CHECK_LIB(resolv, res_query, [ LIBS="$LIBS -lresolv" ]) IPADDR_IN_DISPLAY=yes AC_DEFINE(USE_PIPES) AC_DEFINE(IP_TOS_IS_BROKEN) @@ -910,7 +910,7 @@ [ AC_MSG_RESULT(no) AC_DEFINE(BROKEN_ONE_BYTE_DIRENT_D_NAME, 1, - [Define in your struct dirent expects you to + [Define if your struct dirent expects you to allocate extra space for d_name]) ], [ From dtucker at zip.com.au Thu Nov 24 21:47:05 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 24 Nov 2005 21:47:05 +1100 Subject: [PATCH] Introducing Zero-Knowledge user authentication In-Reply-To: <200511222149.46329.andreas.gaupmann@fh-hagenberg.at> References: <200511222149.46329.andreas.gaupmann@fh-hagenberg.at> Message-ID: <20051124104705.GA20721@gate.dodgy.net.au> On Tue, Nov 22, 2005 at 09:49:40PM +0100, Andreas Gaupmann wrote: > First we would like to describe the purpose of using Zero-Knowledge (ZK) for > user authentication. Traditional authentication methods like > challenge-response with passwords or public keys leak information about the > credentials of a user I'm not qualified to comment on the crypto aspects nor on the prospects for inclusion. That said, I have some comments on the patch itself. Obviously password or C/R authentication leaks authentication information to the server, but how does public-key? (assuming the public-key algorithm has not been broken) Are you referring to a server collecting signatures with various sessionids? >From the patch, it looks like multiple rounds are required. What impact does that have on the authentication times, particularly on high-latency links? You use the string "oo-zk" in the SSH protocol to identify the publickey mechanism you implement. Unless this has been registered with IANA you should use a local method (ie "oo-zk at yourdomain.org") as specified in section 6 of the "SSH Protocol Architecture" document. The OpenBSD patch on your page includes all of the *.orig files, which makes it hard to read. Some of the files you add are under the GPL. This isn't a problem while you're publishing it as a patch, but it would prevent it from being incorporated. You also have some minor errors in the patch (use of C++/c99 "//" style comments, declarations after code eg in key_fingerprint_raw()). While some compilers will permit those, some won't. There's also some whitespace-only changes which are unnecessary. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From stuge-openssh-unix-dev at cdy.org Thu Nov 24 21:51:42 2005 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Thu, 24 Nov 2005 11:51:42 +0100 Subject: Call for release testing In-Reply-To: <20051124200906.18ac8906.djm@mindrot.org> References: <20051124200906.18ac8906.djm@mindrot.org> Message-ID: <20051124105142.16035.qmail@cdy.org> On Thu, Nov 24, 2005 at 08:09:06PM +1100, Damien Miller wrote: > Please send reports of success or failure to > openssh-unix-dev at mindrot.org. Compiles find and all tests pass here on my x86 Gentoo Linux. //Peter From dtucker at zip.com.au Thu Nov 24 22:37:22 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 24 Nov 2005 22:37:22 +1100 Subject: [PATCH] Fix typos and an error In-Reply-To: <20051124092609.GA18902@zeratul.lysator.liu.se> References: <20051124092609.GA18902@zeratul.lysator.liu.se> Message-ID: <20051124113722.GA23272@gate.dodgy.net.au> On Thu, Nov 24, 2005 at 10:26:09AM +0100, Johan Gill wrote: > This patch fixes two typos and one case of wrong parameter ordering > in configure.ac. Applied, thanks. The AC_CHECK_LIB that was changed was within the ncr-sysv block (Reliant UNIX) but it would have never worked as it was. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From vinschen at redhat.com Fri Nov 25 02:16:27 2005 From: vinschen at redhat.com (Corinna Vinschen) Date: Thu, 24 Nov 2005 16:16:27 +0100 Subject: Call for release testing In-Reply-To: <20051124200906.18ac8906.djm@mindrot.org> References: <20051124200906.18ac8906.djm@mindrot.org> Message-ID: <20051124151627.GA26269@calimero.vinschen.de> On Nov 24 20:09, Damien Miller wrote: > Hi All, > > We are planning on doing one of our regular releases (4.3/4.3p1) in > around a week. This is a bugfix release, but a few of the portability > bits have changed, so we would again appreciate testing on as many > systems as possible. Cygwin: Build and tests successfully. Thanks, Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat, Inc. From dtucker at zip.com.au Fri Nov 25 14:54:20 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 25 Nov 2005 14:54:20 +1100 Subject: [PATCH] 64 bit clean compilation patches In-Reply-To: <438364CC.1050302@vranix.com> References: <43823653.3050004@vranix.com> <20051122090957.GA13639@gate.dodgy.net.au> <438364CC.1050302@vranix.com> Message-ID: <20051125035420.GA2840@gate.dodgy.net.au> On Tue, Nov 22, 2005 at 10:34:52AM -0800, Shaw Vrana wrote: > Also troublesome are the following 64-bit related compilation warnings > in scp.c : > > scp.c:589: warning: comparison between signed and unsigned > scp.c:596: warning: comparison between signed and unsigned > > The stat structure likes the off_t, otherwise size_t is used. I'm not > sure what to do with these. Any suggestions for a portable change here? It looks like most of that wants changing to size_t with a sanity check when copying from the off_t in the stat buffer. We're currently prepping for a release, and I think that kind of change would be a bit too invasive to do right now. > - (u_int64_t)off, len); > + (unsigned long long)off, len); I've just applied all of these. They'll be in tomorrow's snapshot, if you could check that I got them all I would appreciate it. Thanks. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From selvesteen at gmail.com Fri Nov 25 21:40:34 2005 From: selvesteen at gmail.com (Michael Selvesteen) Date: Fri, 25 Nov 2005 16:10:34 +0530 Subject: Call for release testing Message-ID: <01ed01c5f1ac$ba1367b0$290110ac@midco> On Nov 24 20:09, Damien Miller wrote: > Hi All, > > We are planning on doing one of our regular releases (4.3/4.3p1) in > around a week. This is a bugfix release, but a few of the portability > bits have changed, so we would again appreciate testing on as many > systems as possible. Build and tests were successful on HP-UX 11.11 & 11.23 platforms. Thanks Michael From Dirk.Kautzsch at gedas.de Sat Nov 26 00:29:59 2005 From: Dirk.Kautzsch at gedas.de (Kautzsch, Dirk) Date: Fri, 25 Nov 2005 14:29:59 +0100 Subject: ssh/scp at Redhat Enterprise 3 (2.4.21-32.ELsmp #1 SMP Fri Apr 15 21:17:59 EDT 2005 i686 i686 i386 GNU/Linux) Message-ID: <4F647C358EA3E74EAA7F8084FE68F48201322E0C@zwisem04.de.gedas-grp> Dear People, I have following situation with "OpenSSH_3.6.1p2, SSH protocols 1.5/2.0, OpenSSL 0x0090701f": a) I will send files via scp to: "OpenSSH_3.8p1, SSH protocols 1.5/2.0, OpenSSL 0.9.7d 17 Mar 2004" b) used command: scp [-vvv] -p -B -C /home/gdg/generation/cr/test_lnx50/lnx50.test2.000001 gdg at lnx50:/home/gdg/EMPFANG/lnx50.test2 Login without PW runs fine, DEBUG3 shows never any errors, but the target file will not be created ! c) used command: scp [-vvv] -p -B -C /home/gdg/generation/cr/test_lnx50/lnx50.test2.000001 gdg at lnx50:/home/gdg/EMPFANG/ <--- without any filename Login without PW runs fine, DEBUG3 shows never any errors, but the target file will be created :-) d) then, I will rename file at remote server via ssh ssh [-vvv] gdg at lnx50 mv -f /home/gdg/EMPFANG/lnx50.test2.000001 /home/gdg/EMPFANG/lnx50.test2 After this action are not more files inside directory ! If I use "cp", then the first file (lnx50.test2.000001) exists - the second (lnx50.test2) are not exists. My comments: All command will be run from a script-deamon that run with "nohup ... &". The script-deamon start the "work-script" via "nohup ... &" and this will execute the scp/ssh-command. The user.environment is correct and available in background. Note: All commands work fine, if I start from a console. May be, It's a special security rule active or the background had a other environment ? Have you any idea ? Thanks in advance and cordial regards, Dirk Kautzsch From zappaboy at gmail.com Sat Nov 26 05:13:26 2005 From: zappaboy at gmail.com (zappaboy) Date: Sat, 26 Nov 2005 01:13:26 +0700 Subject: openssh-SNAP-20051125.tar.gz Message-ID: <903a31230511251013l6a3dd212v555f508b8e1bcaac@mail.gmail.com> I needed this patch to make './configure && make tests' work. From djm at mindrot.org Sat Nov 26 12:53:49 2005 From: djm at mindrot.org (Damien Miller) Date: Sat, 26 Nov 2005 12:53:49 +1100 (EST) Subject: ssh/scp at Redhat Enterprise 3 (2.4.21-32.ELsmp #1 SMP Fri Apr 15 21:17:59 EDT 2005 i686 i686 i386 GNU/Linux) In-Reply-To: <4F647C358EA3E74EAA7F8084FE68F48201322E0C@zwisem04.de.gedas-grp> References: <4F647C358EA3E74EAA7F8084FE68F48201322E0C@zwisem04.de.gedas-grp> Message-ID: 1. Don't cross post 2. Don't send portable OpenSSH requests to openssh at openssh.com. Our webpages make it quite clear that this address is for reporting security and OpenBSD version bugs only 3. Please report problems with Redhat versions of OpenSSH to Redhat -d On Fri, 25 Nov 2005, Kautzsch, Dirk wrote: > Dear People, > > I have following situation with "OpenSSH_3.6.1p2, SSH protocols 1.5/2.0, > OpenSSL 0x0090701f": > > a) I will send files via scp to: "OpenSSH_3.8p1, SSH protocols 1.5/2.0, > OpenSSL 0.9.7d 17 Mar 2004" > > b) used command: > > scp [-vvv] -p -B -C /home/gdg/generation/cr/test_lnx50/lnx50.test2.000001 > gdg at lnx50:/home/gdg/EMPFANG/lnx50.test2 > > Login without PW runs fine, DEBUG3 shows never any errors, but the target > file will not be created ! > > c) used command: > > scp [-vvv] -p -B -C /home/gdg/generation/cr/test_lnx50/lnx50.test2.000001 > gdg at lnx50:/home/gdg/EMPFANG/ <--- without any filename > > Login without PW runs fine, DEBUG3 shows never any errors, but the target > file will be created :-) > > d) then, I will rename file at remote server via ssh > > ssh [-vvv] gdg at lnx50 mv -f /home/gdg/EMPFANG/lnx50.test2.000001 > /home/gdg/EMPFANG/lnx50.test2 > > After this action are not more files inside directory ! > If I use "cp", then the first file (lnx50.test2.000001) exists - the second > (lnx50.test2) are not exists. > > My comments: > > All command will be run from a script-deamon that run with "nohup ... &". > The script-deamon start the "work-script" via "nohup ... &" and this will > execute the scp/ssh-command. > > The user.environment is correct and available in background. > > Note: All commands work fine, if I start from a console. > > May be, It's a special security rule active or the background had a other > environment ? > > Have you any idea ? > > Thanks in advance and cordial regards, > > Dirk Kautzsch > From djm at mindrot.org Sat Nov 26 12:54:50 2005 From: djm at mindrot.org (Damien Miller) Date: Sat, 26 Nov 2005 12:54:50 +1100 (EST) Subject: openssh-SNAP-20051125.tar.gz In-Reply-To: <903a31230511251013l6a3dd212v555f508b8e1bcaac@mail.gmail.com> References: <903a31230511251013l6a3dd212v555f508b8e1bcaac@mail.gmail.com> Message-ID: On Sat, 26 Nov 2005, zappaboy wrote: > I needed this patch to make './configure && make tests' work. Your patch didn't seem to make it. Did you attach it? (make sure it is attached with a MIME type of text/[something] otherwise the mailing list may strip it). -d From zappaman at buraphalinux.org Sat Nov 26 05:03:51 2005 From: zappaman at buraphalinux.org (John Gatewood Ham) Date: Sat, 26 Nov 2005 01:03:51 +0700 (ICT) Subject: test failure for openssh-SNAP-20051125.tar.gz Message-ID: Hello, Testing on my system by doing the requested './configure && make tests' has this crash: ----------------------8< cut here 8<----------------------- test try ciphers: proto 2 cipher acss at openssh.org mac hmac-md5 test try ciphers: proto 2 cipher acss at openssh.org mac hmac-sha1-96 test try ciphers: proto 2 cipher acss at openssh.org mac hmac-md5-96 ok try ciphers run test yes-head.sh ... head: `-2000' option is obsolete; use `-n 2000' Try `head --help' for more information. yes|head returns 0 lines instead of 2000 head: `-2000' option is obsolete; use `-n 2000' Try `head --help' for more information. yes|head returns 0 lines instead of 2000 failed yes pipe head make[1]: *** [t-exec] Error 1 make[1]: Leaving directory `/home/hacker/z/openssh/regress' make: *** [tests] Error 2 $head --version head (coreutils) 5.2.1 Written by David MacKenzie and Jim Meyering. Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ----------------------8< cut here 8<----------------------- The attached patch solved this problem for my system. JGH -------------- next part -------------- --- openssh.orig/regress/yes-head.sh 2003-09-13 03:21:14.000000000 +0700 +++ openssh/regress/yes-head.sh 2005-11-26 00:44:16.000000000 +0700 @@ -4,7 +4,7 @@ tid="yes pipe head" for p in 1 2; do - lines=`${SSH} -$p -F $OBJ/ssh_proxy thishost 'sh -c "while true;do echo yes;done | head -2000"' | (sleep 3 ; wc -l)` + lines=`${SSH} -$p -F $OBJ/ssh_proxy thishost 'sh -c "while true;do echo yes;done | (export _POSIX2_VERSION=199209 ; head -2000)"' | (sleep 3 ; wc -l)` if [ $? -ne 0 ]; then fail "yes|head test failed" lines = 0; From dtucker at zip.com.au Sun Nov 27 23:42:11 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 27 Nov 2005 23:42:11 +1100 Subject: test failure for openssh-SNAP-20051125.tar.gz In-Reply-To: References: Message-ID: <20051127124211.GA5098@gate.dodgy.net.au> On Sat, Nov 26, 2005 at 01:03:51AM +0700, John Gatewood Ham wrote: > head: `-2000' option is obsolete; use `-n 2000' [...] Sigh. If anyone is ever talking to the GNU folks responsible for this, please point out that this breakage is unnecessary. It's even covered in the POSIX.1 FAQ (Q 15): http://www.opengroup.org/austin/papers/posix_faq.html > The attached patch solved this problem for my system. Thanks. Does this slightly simpler patch also solve it? (no export and no subshell) Index: yes-head.sh =================================================================== RCS file: /var/cvs/openssh/regress/yes-head.sh,v retrieving revision 1.3 diff -u -p -r1.3 yes-head.sh --- yes-head.sh 12 Sep 2003 20:21:14 -0000 1.3 +++ yes-head.sh 27 Nov 2005 12:34:13 -0000 @@ -4,7 +4,7 @@ tid="yes pipe head" for p in 1 2; do - lines=`${SSH} -$p -F $OBJ/ssh_proxy thishost 'sh -c "while true;do echo yes;done | head -2000"' | (sleep 3 ; wc -l)` + lines=`${SSH} -$p -F $OBJ/ssh_proxy thishost 'sh -c "while true;do echo yes;done | _POSIX2_VERSION=199209 head -2000"' | (sleep 3 ; wc -l)` if [ $? -ne 0 ]; then fail "yes|head test failed" lines = 0; -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From zappaman at buraphalinux.org Mon Nov 28 01:57:03 2005 From: zappaman at buraphalinux.org (John Gatewood Ham) Date: Sun, 27 Nov 2005 21:57:03 +0700 (ICT) Subject: test failure for openssh-SNAP-20051125.tar.gz In-Reply-To: <20051127124211.GA5098@gate.dodgy.net.au> References: <20051127124211.GA5098@gate.dodgy.net.au> Message-ID: Darren Tucker, Yes your patch works also. Thank you, JGH On Sun, 27 Nov 2005, Darren Tucker wrote: > On Sat, Nov 26, 2005 at 01:03:51AM +0700, John Gatewood Ham wrote: >> head: `-2000' option is obsolete; use `-n 2000' > [...] > > Sigh. If anyone is ever talking to the GNU folks responsible for this, > please point out that this breakage is unnecessary. It's even covered > in the POSIX.1 FAQ (Q 15): > http://www.opengroup.org/austin/papers/posix_faq.html > >> The attached patch solved this problem for my system. > > Thanks. Does this slightly simpler patch also solve it? (no export > and no subshell) > > Index: yes-head.sh > =================================================================== > RCS file: /var/cvs/openssh/regress/yes-head.sh,v > retrieving revision 1.3 > diff -u -p -r1.3 yes-head.sh > --- yes-head.sh 12 Sep 2003 20:21:14 -0000 1.3 > +++ yes-head.sh 27 Nov 2005 12:34:13 -0000 > @@ -4,7 +4,7 @@ > tid="yes pipe head" > > for p in 1 2; do > - lines=`${SSH} -$p -F $OBJ/ssh_proxy thishost 'sh -c "while true;do echo yes;done | head -2000"' | (sleep 3 ; wc -l)` > + lines=`${SSH} -$p -F $OBJ/ssh_proxy thishost 'sh -c "while true;do echo yes;done | _POSIX2_VERSION=199209 head -2000"' | (sleep 3 ; wc -l)` > if [ $? -ne 0 ]; then > fail "yes|head test failed" > lines = 0; > From mdb at juniper.net Mon Nov 28 03:08:55 2005 From: mdb at juniper.net (Mark D. Baushke) Date: Sun, 27 Nov 2005 08:08:55 -0800 Subject: test failure for openssh-SNAP-20051125.tar.gz In-Reply-To: <20051127124211.GA5098@gate.dodgy.net.au> References: <20051127124211.GA5098@gate.dodgy.net.au> Message-ID: <36978.1133107735@juniper.net> Darren Tucker writes: > On Sat, Nov 26, 2005 at 01:03:51AM +0700, John Gatewood Ham wrote: > > head: `-2000' option is obsolete; use `-n 2000' > [...] > > Sigh. If anyone is ever talking to the GNU folks responsible for this, > please point out that this breakage is unnecessary. It's even covered > in the POSIX.1 FAQ (Q 15): > http://www.opengroup.org/austin/papers/posix_faq.html This was already fixed in coreutils 5.3.x (for x>0) as of 2005-04-26. The URLs: http://ftp.gnu.org/pub/gnu/coreutils and ftp://alpha.gnu.org/gnu/coreutils have coreutils-5.91.tar.gz of 2005-10-17 as the lastest stable snapshot as of today. See also: http://lists.gnu.org/archive/html/bug-coreutils/2005-04/msg00169.html as well as http://www.opengroup.org/austin/docs/austin_239.html Of course, just because the lastest development versions have been fixed does not mean that some folks will not be impacted who happen to use older releases of the GNU coreutils package. So, the patch you provided is a good one in any case. -- Mark From Matthias.Gerstner at nefkom.net Mon Nov 28 03:53:12 2005 From: Matthias.Gerstner at nefkom.net (Matthias Gerstner) Date: Sun, 27 Nov 2005 17:53:12 +0100 Subject: OpenSSH and Kerberos / Active Directory authentication problems: Credentials cache permission incorrect / No Credentials Cache found Message-ID: <4389E478.2010009@nefkom.net> Greetings, I'm working on the infrastructure of a medium size client/server environment using an Active Directory running on Windows Server 2003 for central authentication of users on linux clients. Additionally OpenAFS is running using Kerberos authentication through Active Directory as well. Now I want to grant users remote access to their AFS data by logging in into a central OpenSSH server running on linux. As authentication at the Active Directory works well when logging in locally on the linux clients using PAM I wanted to use PAM also for the SSH access. Unfortunately I've run into problems trying to get the OpenSSH setup running. I have tried OpenSSH PAM support and OpenSSH's internal kerberos support. But both result in errors. When using PAM authentication (using the same PAM stack we're using for local authentication on the clients that works with pam_krb5.so) I can successfully login on the OpenSSH server but don't get the Kerberos5 ticket written to /tmp/krb5cc_[...]. The following error is written to the logs: -- -bash: GSSAPI Error: Miscellaneous failure (No Credentials cache found) -- Also the variable KRB5CCNAME isn't defined. I've investigated about this problem already on the net and tried different setups and approaches but to no avail. I need the kerberos5 ticket for use of OpenAFS. When trying internal Kerberos support of OpenSSH I can't login at all while getting the following error messages in the log: -- GSSAPI Error: Miscellaneous failure (Credentials cache permission incorrect) Failed password for from port ssh2 -- I had a look at the responsible source code in auth-krb5.c. By doing some debugging there I found out that the following code fragment fails: auth-krb5.c:137 --- if (!krb5_kuserok(authctxt->krb5_ctx, authctxt->krb5_user, authctxt->pw->pw_name)) { problem = -1; goto out; } --- When I comment out this if-block then I can login using OpenSSH's internal kerberos support and even get my kerberos5 ticket and KRB5CCNAME. I'm not that involved into kerberos on the coding side. What does the krb5_kuserok method do exactly? Why could it fail? Is it critical to comment it out? I'd be happy if somebody had a solution or an advice for me. The best would be to get PAM authentication to correctly write the kerberos ticket to file. Oh, and here is some more data about my OpenSSH server system: It's running on Gentoo Linux using - OpenSSH 4.2_p1 with kerberos, ldap and pam support enabled - mit-krb5-1.4.1-r2 with krb4 support enabled - pam_krb5-1.0-r1 - pam-0.78-r3 Thanks in advance for your support, Matthias Gerstner -- Matthias.Gerstner at nefkom.net From dtucker at zip.com.au Mon Nov 28 17:25:15 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 28 Nov 2005 17:25:15 +1100 Subject: test failure for openssh-SNAP-20051125.tar.gz In-Reply-To: <36978.1133107735@juniper.net> References: <20051127124211.GA5098@gate.dodgy.net.au> <36978.1133107735@juniper.net> Message-ID: <20051128062515.GA32289@gate.dodgy.net.au> On Sun, Nov 27, 2005 at 08:08:55AM -0800, Mark D. Baushke wrote: > Darren Tucker writes: > > > On Sat, Nov 26, 2005 at 01:03:51AM +0700, John Gatewood Ham wrote: > > > head: `-2000' option is obsolete; use `-n 2000' [...] > > This was already fixed in coreutils 5.3.x (for x>0) as of 2005-04-26. That's good news, thanks. I have applied the simpler version of Johns patch to the regress test, so it ought to work either way. Thanks all. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Mon Nov 28 17:48:51 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 28 Nov 2005 17:48:51 +1100 Subject: OpenSSH and Kerberos / Active Directory authentication problems: Credentials cache permission incorrect / No Credentials Cache found In-Reply-To: <4389E478.2010009@nefkom.net> References: <4389E478.2010009@nefkom.net> Message-ID: <20051128064851.GA32705@gate.dodgy.net.au> On Sun, Nov 27, 2005 at 05:53:12PM +0100, Matthias Gerstner wrote: > I'm working on the infrastructure of a medium size client/server > environment using an Active Directory running on Windows Server 2003 for > central authentication of users on linux clients. > Additionally OpenAFS is running using Kerberos authentication through > Active Directory as well. > > Now I want to grant users remote access to their AFS data by logging in > into a central OpenSSH server running on linux. > > As authentication at the Active Directory works well when logging in > locally on the linux clients using PAM I wanted to use PAM also for the > SSH access. > > Unfortunately I've run into problems trying to get the OpenSSH setup > running. I have tried OpenSSH PAM support and OpenSSH's internal > kerberos support. But both result in errors. One thing worth trying: make sure you're using sshd's PasswordAuthentication and not ChallengeResponseAuthentication. You can test this with "ssh -o PreferredAuthentications=password yoursever", and if it works you can set PasswordAuthentication=yes and ChallengeResponseAuthentication=no in sshd_config to require it from your clients. For the gory details see http://bugzilla.mindrot.org/show_bug.cgi?id=688 > When using PAM authentication (using the same PAM stack we're using for > local authentication on the clients that works with pam_krb5.so) I can > successfully login on the OpenSSH server but don't get the Kerberos5 > ticket written to /tmp/krb5cc_[...]. The following error is written to > the logs: > > -- > -bash: GSSAPI Error: Miscellaneous failure (No Credentials cache found) I don't know why bash would care about GSSAPI. > Also the variable KRB5CCNAME isn't defined. I've investigated about this > problem already on the net and tried different setups and approaches but > to no avail. I need the kerberos5 ticket for use of OpenAFS. > > When trying internal Kerberos support of OpenSSH I can't login at all > while getting the following error messages in the log: I can't comment much on the GSSAPI errors, except.. [...] > When I comment out this [krb5_kuserok] then I can login using OpenSSH's > internal kerberos support and even get my kerberos5 ticket and KRB5CCNAME. > I'm not that involved into kerberos on the coding side. What does the > krb5_kuserok method do exactly? Why could it fail? Is it critical to > comment it out? The man page for krb5_kuserok says, in part: This function takes a local user name and verifies if principal is allowed to log in as that user. First krb5_kuserok check if there is a local account name username. If there isn't, krb5_kuserok returns FALSE. Then krb5_kuserok checks if principal is the same as user at realm in any of the default realms. If that is the case, krb5_kuserok returns TRUE. > Oh, and here is some more data about my OpenSSH server system: > It's running on Gentoo Linux using > - OpenSSH 4.2_p1 with kerberos, ldap and pam support enabled The main OpenSSH distribution does not have LDAP support. Is this modified? Have you enabled LDAP support in /etc/nsswitch.conf? > Thanks in advance for your support, You're welcome. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From deengert at anl.gov Tue Nov 29 02:22:25 2005 From: deengert at anl.gov (Douglas E. Engert) Date: Mon, 28 Nov 2005 09:22:25 -0600 Subject: OpenSSH and Kerberos / Active Directory authentication problems: Credentials cache permission incorrect / No Credentials Cache found In-Reply-To: <4389E478.2010009@nefkom.net> References: <4389E478.2010009@nefkom.net> Message-ID: <438B20B1.2080905@anl.gov> Matthias Gerstner wrote: > Greetings, > > I'm working on the infrastructure of a medium size client/server > environment using an Active Directory running on Windows Server 2003 for > central authentication of users on linux clients. > Additionally OpenAFS is running using Kerberos authentication through > Active Directory as well. > This sounds like our site, AD for the KDCs, and OpenAFS, but we have some extra pam routines, pam_afs2 and pam_krb5_ccache, for systems where the vendor's pam_krb5 does not know about AFS. > Now I want to grant users remote access to their AFS data by logging in > into a central OpenSSH server running on linux. > > As authentication at the Active Directory works well when logging in > locally on the linux clients using PAM I wanted to use PAM also for the > SSH access. > > Unfortunately I've run into problems trying to get the OpenSSH setup > running. I have tried OpenSSH PAM support and OpenSSH's internal > kerberos support. But both result in errors. > > When using PAM authentication (using the same PAM stack we're using for > local authentication on the clients that works with pam_krb5.so) I can > successfully login on the OpenSSH server but don't get the Kerberos5 > ticket written to /tmp/krb5cc_[...]. The following error is written to > the logs: > > -- > -bash: GSSAPI Error: Miscellaneous failure (No Credentials cache found) > -- > Does the host have a host/@ principal in the krb5.keytab? > Also the variable KRB5CCNAME isn't defined. I've investigated about this > problem already on the net and tried different setups and approaches but > to no avail. I need the kerberos5 ticket for use of OpenAFS. > DOes it write it to some other location? > When trying internal Kerberos support of OpenSSH I can't login at all > while getting the following error messages in the log: > > -- > GSSAPI Error: Miscellaneous failure (Credentials cache permission incorrect) > Failed password for from port ssh2 > -- > > I had a look at the responsible source code in auth-krb5.c. By doing > some debugging there I found out that the following code fragment fails: > > auth-krb5.c:137 > --- > if (!krb5_kuserok(authctxt->krb5_ctx, authctxt->krb5_user, > authctxt->pw->pw_name)) { > problem = -1; > goto out; > } > --- > > When I comment out this if-block then I can login using OpenSSH's > internal kerberos support and even get my kerberos5 ticket and KRB5CCNAME. > > I'm not that involved into kerberos on the coding side. What does the > krb5_kuserok method do exactly? Why could it fail? Is it critical to > comment it out? Yes it is critical. It is an authorization check that says this user principal is allowed to use this local unix account. It looks at the ~/.k5login and the krb5.conf [realm] auth_to_local variables to do test the mapping. By default, if the kerberos principal is user at realm and the local account is username and user == username and realm == default-realm-of-host, then krb5_kuserok does not need to check the .k5login. (With AD the realm is the uppercase of the AD domain name, fully qualified) > > I'd be happy if somebody had a solution or an advice for me. The best > would be to get PAM authentication to correctly write the kerberos > ticket to file. > > Oh, and here is some more data about my OpenSSH server system: > > It's running on Gentoo Linux using > > - OpenSSH 4.2_p1 with kerberos, ldap and pam support enabled > - mit-krb5-1.4.1-r2 with krb4 support enabled > - pam_krb5-1.0-r1 > - pam-0.78-r3 > > Thanks in advance for your support, > > Matthias Gerstner > -- > Matthias.Gerstner at nefkom.net > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From sudhakar at motorola.com Tue Nov 29 03:05:46 2005 From: sudhakar at motorola.com (KRISHNAMURTHY SUDHAKAR-FSK031) Date: Mon, 28 Nov 2005 10:05:46 -0600 Subject: Password Option for Windows OpenSSH Message-ID: <0B0A39652BB0D411BCCF00508B9512EC1DC690F2@tx14exm05.ftw.mot.com> I am newbie to OpenSSH and have a question on providing password during a client log in session. I am using OpenSSH for Windows(XP) version 3.81p1. Is this the latest version for windows? >From the archive list I gather that OpenSSH will not provide a password option while invoking ssh commands, is this true? or will this be included in the future releases? I read something about using SSH_ASKPASS option to provide the password from a text file. I didn't find this documented anywhere in the list of docs that I obtained while installing 3.81p1, Is this valid for openssh windows ver 3.81p1? or is this just a UNIX/Linux only command? I would appreciate if anyone could tell me if there is a work around for this? TIA From rapier at psc.edu Tue Nov 29 06:23:17 2005 From: rapier at psc.edu (Chris Rapier) Date: Mon, 28 Nov 2005 14:23:17 -0500 Subject: Password Option for Windows OpenSSH In-Reply-To: <0B0A39652BB0D411BCCF00508B9512EC1DC690F2@tx14exm05.ftw.mot.com> References: <0B0A39652BB0D411BCCF00508B9512EC1DC690F2@tx14exm05.ftw.mot.com> Message-ID: <438B5925.5040904@psc.edu> KRISHNAMURTHY SUDHAKAR-FSK031 wrote: > I am newbie to OpenSSH and have a question on providing password during a > client log in session. > I am using OpenSSH for Windows(XP) version 3.81p1. Is this the latest > version for windows? The OpenSSH for Windows listed in the OpenSSH website isn't actually being maintained anymore. The current releases are actually now incorporated into CopSSH - which is a pretty good distribution for windows. >>From the archive list I gather that OpenSSH will not provide a password > option while invoking ssh commands, is this true? or will this be included > in the future releases? > > I read something about using SSH_ASKPASS option to provide the password from > a text file. I didn't find this documented anywhere in the list of docs that > I obtained while installing 3.81p1, Is this valid for openssh windows ver > 3.81p1? or is this just a UNIX/Linux only command? > > I would appreciate if anyone could tell me if there is a work around for > this? You'd actually be a lot better off setting this up using public keys. That way you aren't storing passwords anywhere. From Matthias.Gerstner at nefkom.net Tue Nov 29 06:44:24 2005 From: Matthias.Gerstner at nefkom.net (Matthias Gerstner) Date: Mon, 28 Nov 2005 20:44:24 +0100 Subject: OpenSSH and Kerberos / Active Directory authentication problems: Credentials cache permission incorrect / No Credentials Cache found In-Reply-To: <20051128064851.GA32705@gate.dodgy.net.au> References: <4389E478.2010009@nefkom.net> <20051128064851.GA32705@gate.dodgy.net.au> Message-ID: <438B5E18.4080304@nefkom.net> > One thing worth trying: make sure you're using sshd's > PasswordAuthentication and not ChallengeResponseAuthentication. > > You can test this with "ssh -o PreferredAuthentications=password > yoursever", and if it works you can set PasswordAuthentication=yes > and ChallengeResponseAuthentication=no in sshd_config to > require it from your clients. For the gory details see > http://bugzilla.mindrot.org/show_bug.cgi?id=688 I have already tested configurations with ChallengeResponse enable and disabled and just tested it again but it makes no difference. >>-bash: GSSAPI Error: Miscellaneous failure (No Credentials cache found) > > > I don't know why bash would care about GSSAPI. Probably it's some part of a shell script during the login process > The man page for krb5_kuserok says, in part: > This function takes a local user name and verifies if principal is > allowed to log in as that user. > > First krb5_kuserok check if there is a local account name username. If > there isn't, krb5_kuserok returns FALSE. > > Then krb5_kuserok checks if principal is the same as user at realm in any of > the default realms. If that is the case, krb5_kuserok returns TRUE. Oh there's a man page about it. Good to know. So the function call is important for security as far as I can see. >>- OpenSSH 4.2_p1 with kerberos, ldap and pam support enabled > > > The main OpenSSH distribution does not have LDAP support. Is this modified? > Have you enabled LDAP support in /etc/nsswitch.conf? It's the stable ebuild from gentoo's portage which is rather heavily patched. But I tried vanilla OpenSSH 4.2_p1 already to exclude problems caused from the gentoo patches. LDAP / Kerberos setup is working good. As I said the login process via local console using PAM works reliably. Also kinit on the console works flawless to get tickets and ldapsearch, getent passwd etc. is okay. Well thank you so far. I see what else I can do. Matthias Gerstner From sudhakar at motorola.com Tue Nov 29 07:00:36 2005 From: sudhakar at motorola.com (KRISHNAMURTHY SUDHAKAR-FSK031) Date: Mon, 28 Nov 2005 14:00:36 -0600 Subject: Password Option for Windows OpenSSH Message-ID: <0B0A39652BB0D411BCCF00508B9512EC1DC6997E@tx14exm05.ftw.mot.com> OpenSSH for windows not maintained anymore...that's kind of bummer...the website doesn't say that :( I am looking at COPSSH and I am glad this seems to be an enhanced version of windows openssh. As for the password option, the requirement we have is to use a password and I may not have the option of setting up a public key, given this requirement is their a way to kind of automate the password option?? TIA -----Original Message----- From: Chris Rapier [mailto:rapier at psc.edu] Sent: Monday, November 28, 2005 1:23 PM To: KRISHNAMURTHY SUDHAKAR-FSK031 Cc: openssh-unix-dev at mindrot.org Subject: Re: Password Option for Windows OpenSSH KRISHNAMURTHY SUDHAKAR-FSK031 wrote: > I am newbie to OpenSSH and have a question on providing password > during a client log in session. > I am using OpenSSH for Windows(XP) version 3.81p1. Is this the latest > version for windows? The OpenSSH for Windows listed in the OpenSSH website isn't actually being maintained anymore. The current releases are actually now incorporated into CopSSH - which is a pretty good distribution for windows. >>From the archive list I gather that OpenSSH will not provide a >>password > option while invoking ssh commands, is this true? or will this be > included in the future releases? > > I read something about using SSH_ASKPASS option to provide the > password from a text file. I didn't find this documented anywhere in > the list of docs that I obtained while installing 3.81p1, Is this > valid for openssh windows ver 3.81p1? or is this just a UNIX/Linux only command? > > I would appreciate if anyone could tell me if there is a work around > for this? You'd actually be a lot better off setting this up using public keys. That way you aren't storing passwords anywhere. From Matthias.Gerstner at nefkom.net Tue Nov 29 07:20:51 2005 From: Matthias.Gerstner at nefkom.net (Matthias Gerstner) Date: Mon, 28 Nov 2005 21:20:51 +0100 Subject: OpenSSH and Kerberos / Active Directory authentication problems: Credentials cache permission incorrect / No Credentials Cache found In-Reply-To: <438B20B1.2080905@anl.gov> References: <4389E478.2010009@nefkom.net> <438B20B1.2080905@anl.gov> Message-ID: <438B66A3.2040402@nefkom.net> Douglas E. Engert wrote: > This sounds like our site, AD for the KDCs, and OpenAFS, but we have some > extra pam routines, pam_afs2 and pam_krb5_ccache, for systems where the vendor's > pam_krb5 does not know about AFS. In my case it's part of the infrastructure at my university. We're running the Kerberos/OpenAFS setup for about three months now on about 100 clients with Gentoo Linux. On the pam side we use pam_krb5 for authentication and pam_openafs_session from debian for getting AFS tokens during login. We're still gaining experience with this setup. It's running surprisingly stable after a hard time for setting up the whole thing. Only the OpenSSH issue is causing some headache now. >>-- >>-bash: GSSAPI Error: Miscellaneous failure (No Credentials cache found) >>-- >> > > > Does the host have a host/@ principal in the krb5.keytab? No there's no such keytab entry on the OpenSSH server. Is it needed? I'm sorry that I'm not too familiar with kerberos as I first began working with it related to the mentioned infrastructure setup. I didn't think that there's needed any additional kerberos setup / communication when wanting to login via a ssh server. >>Also the variable KRB5CCNAME isn't defined. I've investigated about this >>problem already on the net and tried different setups and approaches but >>to no avail. I need the kerberos5 ticket for use of OpenAFS. >> > > > DOes it write it to some other location? I don't see a trace of the kerberos ticket. klist does not recognize anything. The only thing I can imagine is that OpenSSH is keeping the ticket in memory as I've read in some older postings on the net. And there have also been discussed issues about the KRB5CCNAME environment variable being defined too late in the pam processing when using OpenSSH. But this postings are mostly rather old and I guess these problems are fixed in the meantime. But my problem may be somehow similar to the before mentioned ones. > Yes it is critical. It is an authorization check that says this > user principal is allowed to use this local unix account. > > It looks at the ~/.k5login and the krb5.conf [realm] auth_to_local > variables to do test the mapping. > > By default, if the kerberos principal is user at realm and the local account > is username and user == username and realm == default-realm-of-host, > then krb5_kuserok does not need to check the .k5login. > > (With AD the realm is the uppercase of the AD domain name, fully qualified) These conditions all apply to my setup. The AD domain name is the default realm in krb5.conf and unix usernames are the same as the kerberos usernames. krb5.conf: -- [libdefaults] default_realm = SOME.DOMAIN.DE [,,,] kinit in66666 Password for in66666 at SOME.DOMAIN.DE [...] id in66666 uid=66666(in66666) [...] So everything should be allright with krb5_kuserok ... Thanks so far, Matthias Gerstner From deengert at anl.gov Tue Nov 29 09:54:46 2005 From: deengert at anl.gov (Douglas E. Engert) Date: Mon, 28 Nov 2005 16:54:46 -0600 Subject: OpenSSH and Kerberos / Active Directory authentication problems: Credentials cache permission incorrect / No Credentials Cache found In-Reply-To: <438B66A3.2040402@nefkom.net> References: <4389E478.2010009@nefkom.net> <438B20B1.2080905@anl.gov> <438B66A3.2040402@nefkom.net> Message-ID: <438B8AB6.4090206@anl.gov> Matthias Gerstner wrote: > Douglas E. Engert wrote: > > >>This sounds like our site, AD for the KDCs, and OpenAFS, but we have some >>extra pam routines, pam_afs2 and pam_krb5_ccache, for systems where the vendor's >>pam_krb5 does not know about AFS. > > > In my case it's part of the infrastructure at my university. We're > running the Kerberos/OpenAFS setup for about three months now on about > 100 clients with Gentoo Linux. > On the pam side we use pam_krb5 for authentication and > pam_openafs_session from debian for getting AFS tokens during login. During login using a password, Kerberos should get you two tickets, one it the ticket granting ticket, the other is a service ticket for the local host. The second ticket is need to avoid an attack where a user replaces the network, and the KDC with ther own version then use the password stored in their KDC to login to the host. This attack will not work if the host tries to get the second ticket, as it holds the real key for the host in the krb5.keytab, and can detect a bogus KDC. The krb5.keytab may also be called a servtab, The name has changed over the years. I bet that with the pam_krb5 you have not set the validate option or some thing similiar. This option does the above check. On a peronal workstaion, you may be willing to live with the above attack. OpenSSH gets the service ticket. The man sshd_config states in the kerberosAuthentication sesion that you must have a servtab. Also if you use gssapi for authenticaiton you must have the krb5.keytab or servtab as well. > > We're still gaining experience with this setup. It's running > surprisingly stable after a hard time for setting up the whole thing. > Only the OpenSSH issue is causing some headache now. > > >>>-- >>>-bash: GSSAPI Error: Miscellaneous failure (No Credentials cache found) >>>-- >>> >> >> >>Does the host have a host/@ principal in the krb5.keytab? > > > No there's no such keytab entry on the OpenSSH server. Is it needed? Yes see above. > > I'm sorry that I'm not too familiar with kerberos as I first began > working with it related to the mentioned infrastructure setup. > > I didn't think that there's needed any additional kerberos setup / > communication when wanting to login via a ssh server. > > >>>Also the variable KRB5CCNAME isn't defined. I've investigated about this >>>problem already on the net and tried different setups and approaches but >>>to no avail. I need the kerberos5 ticket for use of OpenAFS. >>> Once you get the krb5.keytab setup, this should also work. The problems where prior to 3.9 I believe. >> >> >>DOes it write it to some other location? > > > I don't see a trace of the kerberos ticket. klist does not recognize > anything. The only thing I can imagine is that OpenSSH is keeping the > ticket in memory as I've read in some older postings on the net. > > And there have also been discussed issues about the KRB5CCNAME > environment variable being defined too late in the pam processing when > using OpenSSH. But this postings are mostly rather old and I guess these > problems are fixed in the meantime. > > But my problem may be somehow similar to the before mentioned ones. > > >>Yes it is critical. It is an authorization check that says this >>user principal is allowed to use this local unix account. >> >>It looks at the ~/.k5login and the krb5.conf [realm] auth_to_local >>variables to do test the mapping. >> >>By default, if the kerberos principal is user at realm and the local account >>is username and user == username and realm == default-realm-of-host, >>then krb5_kuserok does not need to check the .k5login. >> >>(With AD the realm is the uppercase of the AD domain name, fully qualified) > > > These conditions all apply to my setup. The AD domain name is the > default realm in krb5.conf and unix usernames are the same as the > kerberos usernames. > > krb5.conf: > -- > [libdefaults] > default_realm = SOME.DOMAIN.DE > [,,,] > > kinit in66666 > Password for in66666 at SOME.DOMAIN.DE > [...] > > id in66666 > uid=66666(in66666) [...] > > So everything should be allright with krb5_kuserok ... > > Thanks so far, > > Matthias Gerstner > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From dtucker at zip.com.au Tue Nov 29 12:24:55 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 29 Nov 2005 12:24:55 +1100 Subject: Password Option for Windows OpenSSH In-Reply-To: <438B5925.5040904@psc.edu> References: <0B0A39652BB0D411BCCF00508B9512EC1DC690F2@tx14exm05.ftw.mot.com> <438B5925.5040904@psc.edu> Message-ID: <438BADE7.4060508@zip.com.au> Chris Rapier wrote: > The OpenSSH for Windows listed in the OpenSSH website isn't actually > being maintained anymore. The current releases are actually now > incorporated into CopSSH - which is a pretty good distribution for windows. COPSSH is listed there too (http://openssh.com/windows.html). I'll put a little comment next to the sshwindows link noting that it appears unmaintained. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From vinschen at redhat.com Tue Nov 29 20:51:34 2005 From: vinschen at redhat.com (Corinna Vinschen) Date: Tue, 29 Nov 2005 10:51:34 +0100 Subject: Password Option for Windows OpenSSH In-Reply-To: <0B0A39652BB0D411BCCF00508B9512EC1DC6997E@tx14exm05.ftw.mot.com> References: <0B0A39652BB0D411BCCF00508B9512EC1DC6997E@tx14exm05.ftw.mot.com> Message-ID: <20051129095134.GA19913@calimero.vinschen.de> On Nov 28 14:00, KRISHNAMURTHY SUDHAKAR-FSK031 wrote: > > OpenSSH for windows not maintained anymore...that's kind of bummer...the > website doesn't say that :( > I am looking at COPSSH and I am glad this seems to be an enhanced version of > windows openssh. You're aware that "OpenSSH for Windows" as well as CopSSH are just convenience packages of OpenSSH for Cygwin, aren't you? You get the same functionality when using OpenSSH within the official Cygwin net distribution (http://cygwin.com), just with the difference that the net distribution always has the latest Cygwin DLL and the latest OpenSSH version available, 4.2p1 right now. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat, Inc. From rapier at psc.edu Wed Nov 30 04:21:51 2005 From: rapier at psc.edu (Chris Rapier) Date: Tue, 29 Nov 2005 12:21:51 -0500 Subject: Password Option for Windows OpenSSH In-Reply-To: <20051129095134.GA19913@calimero.vinschen.de> References: <0B0A39652BB0D411BCCF00508B9512EC1DC6997E@tx14exm05.ftw.mot.com> <20051129095134.GA19913@calimero.vinschen.de> Message-ID: <438C8E2F.1000207@psc.edu> Which is a great idea if someone wants to install all of cygwin. However, if they don't and just want ssh then CopSSH is a fine solution. You get the bare minimum you need to run ssh and thats it - which is all a lot of people want. Corinna Vinschen wrote: > On Nov 28 14:00, KRISHNAMURTHY SUDHAKAR-FSK031 wrote: >> >> OpenSSH for windows not maintained anymore...that's kind of bummer...the >> website doesn't say that :( >> I am looking at COPSSH and I am glad this seems to be an enhanced version of >> windows openssh. > > You're aware that "OpenSSH for Windows" as well as CopSSH are just > convenience packages of OpenSSH for Cygwin, aren't you? You get the > same functionality when using OpenSSH within the official Cygwin net > distribution (http://cygwin.com), just with the difference that the net > distribution always has the latest Cygwin DLL and the latest OpenSSH > version available, 4.2p1 right now. > > > Corinna > From andreas.gaupmann at fh-hagenberg.at Wed Nov 30 08:23:17 2005 From: andreas.gaupmann at fh-hagenberg.at (Andreas Gaupmann) Date: Tue, 29 Nov 2005 22:23:17 +0100 Subject: [PATCH] Introducing Zero-Knowledge user authentication In-Reply-To: <20051124104705.GA20721@gate.dodgy.net.au> References: <200511222149.46329.andreas.gaupmann@fh-hagenberg.at> <20051124104705.GA20721@gate.dodgy.net.au> Message-ID: <200511292223.38617.andreas.gaupmann@fh-hagenberg.at> Hello! On Thursday 24 November 2005 11:47, Darren Tucker wrote: > I'm not qualified to comment on the crypto aspects nor on the prospects > for inclusion. > Can you give us some advice on how to achieve or suggest such an inclusion? Who are the people we can ask about it? > Obviously password or C/R authentication leaks authentication information > to the server, but how does public-key? (assuming the public-key > algorithm has not been broken) Are you referring to a server collecting > signatures with various sessionids? > Basically yes. Conventional public-key methods of authentication leak information, because every signature contains some information about the private key which could be used to break the key. Zero-knowledge proofs of knowledge (of some private key, in our case) on the other hand yield nothing but their validity. No matter how cunningly you choose challenge values and how often you run the protocol successively, you still know nothing more than that the prover knows the secret key. There's nothing wrong with using public-key authentication in a practice, because it's highly unlikely that any adversary would know what to do with the information contained in public-key signatures. In theory, however, the difference is significant. Look at it this way: Using zero-knowledge is a way to reduce the security assumptions even further (to the basic "factorization is infeasible"), and I believe that it's worth to go the extra mile for that. > From the patch, it looks like multiple rounds are required. What impact > does that have on the authentication times, particularly on high-latency > links? > We have not yet made any benchmarks that allow an objective comparison of the authentication times needed by the different user authentication methods. We are working on it. The authentication times with ZK were short during the tests of our patch and no annoying delays were encountered. > You use the string "oo-zk" in the SSH protocol to identify the publickey > mechanism you implement. Unless this has been registered with IANA you > should use a local method (ie "oo-zk at yourdomain.org") as specified in > section 6 of the "SSH Protocol Architecture" document. > The string "oo-zk" ist only used as new type for the ssh-keygen. Do you mean the name of the authentication method in the Authmethod structure? We have changed that name now from zk at cms.ac to zk. > The OpenBSD patch on your page includes all of the *.orig files, which > makes it hard to read. > > Some of the files you add are under the GPL. This isn't a problem while > you're publishing it as a patch, but it would prevent it from being > incorporated. > > You also have some minor errors in the patch (use of C++/c99 "//" style > comments, declarations after code eg in key_fingerprint_raw()). While > some compilers will permit those, some won't. There's also some > whitespace-only changes which are unnecessary. > All these things are fixed now. We are constantly learning. The new patches can be downloaded from http://zk-ssh.cms.ac/ Thanks for your opinion and suggestions. Regards -Ulrich Zehl -Andreas Gaupmann -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20051129/ffdc3500/attachment.bin From aleksey at hotmail.com Wed Nov 30 12:18:54 2005 From: aleksey at hotmail.com (Alexei Potashnik) Date: Tue, 29 Nov 2005 17:18:54 -0800 Subject: sshd 4.2p1 LocalForward interface binding Message-ID: There seems to be a change in the logic that sshd uses in selecting interface to bind for LocalForward requests from the client. I have the following setup: ssh client (10.0.0.1) configured with "LocalForward 1080 127.0.0.1:1080" is connecting to sshd server (192.168.0.1). Before installing openssh-4.2p1 sshd would successfully establish a forwarding connection for the client: 127.0.0.1:xxx -> 127.0.0.1:1080 After installing 4.2p1, sshd still attempts to establish the connection, but from whatever interface client connected to, so now connection looks like this: 192.168.0.1:xxx -> 127.0.0.1:1080 Is this a bug or a feature? If this is a feature, is there a way to control this binding logic? GatewayPorts setting on sshd doesn't seem to make any difference (I guess it only affects RemoteForward commands). Lack of this control becomes a headache, when 192.168.0.1 address is DHCP assigned and you try to enforce policy of connections from localhost only for sockd server running on 127.0.0.1:1080... Thank you Alexei From sudhakar at motorola.com Wed Nov 30 16:04:46 2005 From: sudhakar at motorola.com (KRISHNAMURTHY SUDHAKAR-FSK031) Date: Tue, 29 Nov 2005 23:04:46 -0600 Subject: Password Option for Windows OpenSSH Message-ID: <0B0A39652BB0D411BCCF00508B9512EC1DCEB097@tx14exm05.ftw.mot.com> I totally agree with you...for our project we can't use cygwin because of the high licensing cost involved with it...copssh just does great for us...except I am still trying to get around the issue of using a command line option for the password. Need to explore the option of using a perl script to do this... Does anyone know if I can recompile the code by providing a password option?? If so where do I start? Any suggestions is greatly appreciated. -----Original Message----- From: openssh-unix-dev-bounces+sudhakar=motorola.com at mindrot.org [mailto:openssh-unix-dev-bounces+sudhakar=motorola.com at mindrot.org] On Behalf Of Chris Rapier Sent: Tuesday, November 29, 2005 11:22 AM To: openssh-unix-dev at mindrot.org Subject: Re: Password Option for Windows OpenSSH Which is a great idea if someone wants to install all of cygwin. However, if they don't and just want ssh then CopSSH is a fine solution. You get the bare minimum you need to run ssh and thats it - which is all a lot of people want. Corinna Vinschen wrote: > On Nov 28 14:00, KRISHNAMURTHY SUDHAKAR-FSK031 wrote: >> >> OpenSSH for windows not maintained anymore...that's kind of >> bummer...the website doesn't say that :( I am looking at COPSSH and I >> am glad this seems to be an enhanced version of windows openssh. > > You're aware that "OpenSSH for Windows" as well as CopSSH are just > convenience packages of OpenSSH for Cygwin, aren't you? You get the > same functionality when using OpenSSH within the official Cygwin net > distribution (http://cygwin.com), just with the difference that the > net distribution always has the latest Cygwin DLL and the latest > OpenSSH version available, 4.2p1 right now. > > > Corinna > _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From djm at mindrot.org Wed Nov 30 16:08:07 2005 From: djm at mindrot.org (Damien Miller) Date: Wed, 30 Nov 2005 16:08:07 +1100 (EST) Subject: Password Option for Windows OpenSSH In-Reply-To: <0B0A39652BB0D411BCCF00508B9512EC1DCEB097@tx14exm05.ftw.mot.com> References: <0B0A39652BB0D411BCCF00508B9512EC1DCEB097@tx14exm05.ftw.mot.com> Message-ID: On Tue, 29 Nov 2005, KRISHNAMURTHY SUDHAKAR-FSK031 wrote: > I totally agree with you...for our project we can't use cygwin because of > the high licensing cost involved with it...copssh just does great for Cygwin's licensing cost is zero. It is free, open source software. From rapier at psc.edu Wed Nov 30 16:17:40 2005 From: rapier at psc.edu (Chris Rapier) Date: Wed, 30 Nov 2005 00:17:40 -0500 Subject: Password Option for Windows OpenSSH In-Reply-To: <0B0A39652BB0D411BCCF00508B9512EC1DCEB097@tx14exm05.ftw.mot.com> References: <0B0A39652BB0D411BCCF00508B9512EC1DCEB097@tx14exm05.ftw.mot.com> Message-ID: <438D35F4.1000205@psc.edu> Make sure password authentication is enabled. However, I got copssh to work with passwords out of the box. Shouldn't be a problem as long as the users on the xp box have passwords. Now, if you can use passwords but just need an automation method you should be able to use one of the 'expect' ports to automate the whole process. http://expect.nist.gov/ has some native ports for XP. I still suggest against using passwords stored in this manner but if you can't use keys and this has to be automated I'm not sure if ssh can do what you want it to do on its own. KRISHNAMURTHY SUDHAKAR-FSK031 wrote: > I totally agree with you...for our project we can't use cygwin because of > the high licensing cost involved with it...copssh just does great for > us...except I am still trying to get around the issue of using a command > line option for the password. > Need to explore the option of using a perl script to do this... > Does anyone know if I can recompile the code by providing a password > option?? If so where do I start? Any suggestions is greatly appreciated. > > -----Original Message----- > From: openssh-unix-dev-bounces+sudhakar=motorola.com at mindrot.org > [mailto:openssh-unix-dev-bounces+sudhakar=motorola.com at mindrot.org] On > Behalf Of Chris Rapier > Sent: Tuesday, November 29, 2005 11:22 AM > To: openssh-unix-dev at mindrot.org > Subject: Re: Password Option for Windows OpenSSH > > Which is a great idea if someone wants to install all of cygwin. > However, if they don't and just want ssh then CopSSH is a fine solution. > You get the bare minimum you need to run ssh and thats it - which is all a > lot of people want. > > Corinna Vinschen wrote: >> On Nov 28 14:00, KRISHNAMURTHY SUDHAKAR-FSK031 wrote: >>> >>> OpenSSH for windows not maintained anymore...that's kind of >>> bummer...the website doesn't say that :( I am looking at COPSSH and I >>> am glad this seems to be an enhanced version of windows openssh. >> You're aware that "OpenSSH for Windows" as well as CopSSH are just >> convenience packages of OpenSSH for Cygwin, aren't you? You get the >> same functionality when using OpenSSH within the official Cygwin net >> distribution (http://cygwin.com), just with the difference that the >> net distribution always has the latest Cygwin DLL and the latest >> OpenSSH version available, 4.2p1 right now. >> >> >> Corinna >> > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From rapier at psc.edu Wed Nov 30 16:19:56 2005 From: rapier at psc.edu (Chris Rapier) Date: Wed, 30 Nov 2005 00:19:56 -0500 Subject: Password Option for Windows OpenSSH In-Reply-To: References: <0B0A39652BB0D411BCCF00508B9512EC1DCEB097@tx14exm05.ftw.mot.com> Message-ID: <438D367C.4030102@psc.edu> Damien Miller wrote: > > On Tue, 29 Nov 2005, KRISHNAMURTHY SUDHAKAR-FSK031 wrote: > >> I totally agree with you...for our project we can't use cygwin because of >> the high licensing cost involved with it...copssh just does great for > > Cygwin's licensing cost is zero. It is free, open source software. He might be thinking of the red hat cygwin product. Still, installing all of cygwin just to get ssh is a bit like buying a bakery just to get a loaf of bread. From djm at mindrot.org Wed Nov 30 16:27:47 2005 From: djm at mindrot.org (Damien Miller) Date: Wed, 30 Nov 2005 16:27:47 +1100 (EST) Subject: Password Option for Windows OpenSSH In-Reply-To: <438D367C.4030102@psc.edu> References: <0B0A39652BB0D411BCCF00508B9512EC1DCEB097@tx14exm05.ftw.mot.com> <438D367C.4030102@psc.edu> Message-ID: On Wed, 30 Nov 2005, Chris Rapier wrote: > He might be thinking of the red hat cygwin product. Still, installing all of > cygwin just to get ssh is a bit like buying a bakery just to get a loaf of > bread. You can install as much, or as little of Cygwin as you like. If you want, this can be just OpenSSH + OpenSSL + cygwin.dll + bash (pretty much what the 3rd party repackagings do). -d From jakob at rfc.se Wed Nov 30 18:28:03 2005 From: jakob at rfc.se (Jakob Schlyter) Date: Wed, 30 Nov 2005 08:28:03 +0100 (CET) Subject: Call for release testing In-Reply-To: <20051124200906.18ac8906.djm@mindrot.org> References: <20051124200906.18ac8906.djm@mindrot.org> Message-ID: On Thu, 24 Nov 2005, Damien Miller wrote: > We are planning on doing one of our regular releases (4.3/4.3p1) in > around a week. This is a bugfix release, but a few of the portability > bits have changed, so we would again appreciate testing on as many > systems as possible. at the same time I'd like feedback on and testing of the SSHFP DNS feature as some people has reported problems. See README.dns for more information. jakob From jakob at rfc.se Wed Nov 30 18:44:10 2005 From: jakob at rfc.se (Jakob Schlyter) Date: Wed, 30 Nov 2005 08:44:10 +0100 (CET) Subject: Call for release testing In-Reply-To: <20051124200906.18ac8906.djm@mindrot.org> References: <20051124200906.18ac8906.djm@mindrot.org> Message-ID: On Thu, 24 Nov 2005, Damien Miller wrote: > Running the regression tests supplied with Portable does not require > installation and is a simply: > > $ ./configure && make tests openssh-SNAP-20031223 on Darwin xyzzy 8.3.0 Darwin Kernel Version 8.3.0: Mon Oct 3 20:04:04 PDT 2005; root:xnu-792.6.22.obj~2/RELEASE_PPC Power Macintosh powerpc 'make tests' exited with run test agent-getpeereid.sh ... ssh-add did not fail for nobody: 1 < 2 failed disallow agent attach from other uid make[1]: *** [t-exec] Error 1 make: *** [tests] Error 2 jakob From vinschen at redhat.com Wed Nov 30 20:11:35 2005 From: vinschen at redhat.com (Corinna Vinschen) Date: Wed, 30 Nov 2005 10:11:35 +0100 Subject: Password Option for Windows OpenSSH In-Reply-To: <0B0A39652BB0D411BCCF00508B9512EC1DCEB097@tx14exm05.ftw.mot.com> References: <0B0A39652BB0D411BCCF00508B9512EC1DCEB097@tx14exm05.ftw.mot.com> Message-ID: <20051130091135.GC2999@calimero.vinschen.de> On Nov 29 23:04, KRISHNAMURTHY SUDHAKAR-FSK031 wrote: > I totally agree with you...for our project we can't use cygwin because of > the high licensing cost involved with it...copssh just does great for > us...except I am still trying to get around the issue of using a command > line option for the password. There are a few misperceptions here. First of all, CopSSH is based on Cygwin and delivers a Cygwin DLL with it. So you're *not* off the hook as far as the Cygwin DLL's licensing goes, just because you download it as part of another project. You still have to adhere to the license. The Cygwin license is GPL with an extra bit. The GPL requires the project to give away the sources of the Cygwin DLL together with the binaries (one way or the other). CopSSH is not providing the sources for the Cygwin DLL it delivers and is clearly infringing the Cygwin license. I'm just going to get in touch with the CopSSH maintainer. OSS appliations linked against the Cygwin DLL are not automatically GPLed, but retain their specific licensing. As long as you're only using OSS tools linked against Cygwin, like OpenSSH (also within the CopSSH package), that's fine. Proprietary applications are not covered by this. They have to go GPL when linked against the Cygwin DLL, or the company has to purchase a buyout license from Red Hat. So, bottom line, as long as you just use OSS tools, you don't have to purchase a Cygwin buyout license. This is only necessary when you link your own, proprietary applications against Cygwin, and want to keep your applications proprietary. Since I guess further discussions are way off-topic, please ask further questions at the cygwin-licensing AT cygwin DOT com mailing list. It's a lowest volume, managed mailing list. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat, Inc. From f_mohr at yahoo.de Wed Nov 30 20:43:23 2005 From: f_mohr at yahoo.de (Frank Mohr) Date: Wed, 30 Nov 2005 10:43:23 +0100 Subject: ClientAliveInterval Question Message-ID: <438D743B.4080507@yahoo.de> Hi is there a reason why the ClientAliveInterval is 0 (i.e. turned of) by default? frank ___________________________________________________________ Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de From dtucker at zip.com.au Wed Nov 30 20:58:26 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 30 Nov 2005 20:58:26 +1100 Subject: ClientAliveInterval Question In-Reply-To: <438D743B.4080507@yahoo.de> References: <438D743B.4080507@yahoo.de> Message-ID: <20051130095826.GA505@gate.dodgy.net.au> On Wed, Nov 30, 2005 at 10:43:23AM +0100, Frank Mohr wrote: > is there a reason why the ClientAliveInterval is 0 (i.e. turned of) > by default? In theory, it's not needed. If an IP network works the way it's supposed to then it's unnecessary. In fact, it makes things worse: it keeps demand-dial links active when they need not be, and causes idle connections to abort during intermittent network problems when they need not. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From djm at mindrot.org Wed Nov 30 21:19:34 2005 From: djm at mindrot.org (Damien Miller) Date: Wed, 30 Nov 2005 21:19:34 +1100 Subject: Call for release testing In-Reply-To: References: <20051124200906.18ac8906.djm@mindrot.org> Message-ID: <438D7CB6.90607@mindrot.org> Jakob Schlyter wrote: > run test agent-getpeereid.sh ... > ssh-add did not fail for nobody: 1 < 2 > failed disallow agent attach from other uid > make[1]: *** [t-exec] Error 1 > make: *** [tests] Error 2 Known problem: Apple don't implement getpeereid(). Users should complain to them that their OS lacks a critical security feature. -d