From senthilkumar_sen at hotpop.com  Sat Jul  2 03:50:31 2005
From: senthilkumar_sen at hotpop.com (Senthil Kumar)
Date: Fri, 1 Jul 2005 23:20:31 +0530
Subject: sshd deletes the GSSAPI ticket on exit
References: <Pine.LNX.4.44.0506291012530.30073-100000@hadrian.inf.ed.ac.uk>
Message-ID: <68c601c57e65$64a10cc0$220110ac@sekco>

Simon wrote:
> Secondly, whilst OpenSSH does call pam_setcred(DELETE_CRED) on session
> exit, it only does so if an earlier call successfully established
> credentials. The danger is that many PAM modules also call their setcred()
> function when close_session() is called.

Ya, its the variable sshpam_cred_established that is responsible for this.

> So, it's not really OpenSSH's problem. I'd suggest speaking to the vendor
> of your PAM module.
>

Ok, Let me check with them.

Darren wrote:
>Sounds like the underlying problem is that you PAM module is zapping
>credential caches that it didn't create.

Yes, it checks first for its credential and if not found deletes the one it
doesn't create.

Thanks,
Senthil.


----- Original Message ----- 
From: <sxw at inf.ed.ac.uk>
To: "Senthil Kumar" <senthilkumar_sen at hotpop.com>
Cc: "OpenSSH Devel List" <openssh-unix-dev at mindrot.org>
Sent: Wednesday, June 29, 2005 2:53 PM
Subject: Re: sshd deletes the GSSAPI ticket on exit


> On Wed, 29 Jun 2005, Senthil Kumar wrote:
>
>> I have run into a situation where a user exiting from a
>> PAM_KERBEROS-authenticated session runs the risk of deleting a
>> kinit-generated credentials file that was already sitting on the server.
>
> There seem to be a number of misconceptions in your email.
>
> Firstly, what you're describing has nothing at all to do with GSSAPI, or
> the support for GSSAPI in OpenSSH. GSSAPI is an API which provides a means
> of performing authentication options - it doesn't provide ticket formats
> or storage - both are properties of the underlying authentication
> mechanism.
>
> Secondly, whilst OpenSSH does call pam_setcred(DELETE_CRED) on session
> exit, it only does so if an earlier call successfully established
> credentials. The danger is that many PAM modules also call their setcred()
> function when close_session() is called.
>
> Finally, if a PAM module deletes a ccache that it didn't create, then that
> module is broken. Certainly, if it works in the way that you describe
> and trusts the KRB5CCNAME varibale, its fundamentaly flawed.
>
> So, it's not really OpenSSH's problem. I'd suggest speaking to the vendor
> of your PAM module.
>
> Cheers,
>
> Simon.
>
>
> 




From breeze at smsonline.com  Sat Jul  2 09:20:50 2005
From: breeze at smsonline.com (Bill Rees)
Date: Fri, 01 Jul 2005 16:20:50 -0700
Subject: auto login failure: PEM_read_PrivateKey
Message-ID: <42C5CFD2.3070701@smsonline.com>

Hey All,

    Can anyone tell me what the following message implies?  What does 
PEM_read_PrivateKey do and why would it fail?
    This is the result of trying to setup ssh for autologin.  Though I 
follow the man page, it doesn't work.

        debug1: PEM_read_PrivateKey failed


Thanks,
Bill Rees


More Debug Output
==========

debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: 
publickey,gssapi-with-mic,password,keyboard-interactive
debug1: Next authentication method: publickey
debug2: userauth_pubkey_agent: no keys at all
debug2: userauth_pubkey_agent: no more keys
debug2: userauth_pubkey_agent: no message sent
debug1: Trying private key: /home/breeze/.ssh/identity
debug1: Trying private key: /home/breeze/.ssh/id_rsa
debug1: Offering public key: /home/breeze/.ssh/id_dsa
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-dss blen 432 lastkey 0x80860f0 hint 2
debug2: input_userauth_pk_ok: fp 
9e:72:3d:cd:6f:87:cf:aa:8e:d6:3d:71:18:04:99:7a

        debug1: PEM_read_PrivateKey failed

debug1: read PEM private key done: type <unknown>









From dtucker at zip.com.au  Sat Jul  2 11:07:00 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Sat, 02 Jul 2005 11:07:00 +1000
Subject: auto login failure: PEM_read_PrivateKey
In-Reply-To: <42C5CFD2.3070701@smsonline.com>
References: <42C5CFD2.3070701@smsonline.com>
Message-ID: <42C5E8B4.5020502@zip.com.au>

Bill Rees wrote:
>     Can anyone tell me what the following message implies?  What does 
> PEM_read_PrivateKey do and why would it fail?
>     This is the result of trying to setup ssh for autologin.  Though I 
> follow the man page, it doesn't work.
> 
>         debug1: PEM_read_PrivateKey failed

THis means that attempting to read the private key 
/home/breeze/.ssh/id_dsa for some reason.  Potential reasons are:

a) corrupt private key file.  Try regenerating it with ssh-keygen.

b) openssl build problems.  Did OpenSSL's "make test" pass?

What platform and compiler are you using?

You can test if OpenSSL can read the keys with something like:
$ openssl dsa -in ~/.ssh/id_dsa -noout

-- 
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 bob at proulx.com  Sun Jul  3 12:29:45 2005
From: bob at proulx.com (Bob Proulx)
Date: Sat, 2 Jul 2005 20:29:45 -0600
Subject: sshd_config parameter to deal with multiple failed logins
In-Reply-To: <05062920105250@alpha9.rhul.ac.uk>
References: <05062920105250@alpha9.rhul.ac.uk>
Message-ID: <20050703022945.GA32559@dementia.proulx.com>

Tom Crane wrote:
> Please could responders CC me since I'm not on the mailing list. 
> Does anyone know if there are plans to give sshd the ability to block
> further login attempts from a particular IP address/block after a set
> number of failed logins?

Having personally experienced being locked out of systems because of
admins that have set up such things let me say that setting up
blocking because of failed logins is a Bad Thing.  The reasons can be
simply that someone on the system with an id near yours misspells it a
lot and therefore always locks out the legitimate user.  Or it could
be that you don't like someone and so intentionally lock them out of
their accounts out of spite.  Regardless, it trivially leads to a
denial of service attack against valid users.

The usual way to handle this for people who insist upon doing
something about it is to rate limit the login attempts.  Requiring a
small number of seconds between login attempts is sufficient to
prevent brute force attacks but still allow valid users to log into
the system.

> I'm sure lots of other admins have seen their system logs full of
> attempts by hackers probing with lists of sample usernames.

Yes.  My logs are filled with those.  And my login is plain and
commonly tried in dictionary attacks so I often see it there.  But I
am not concerned by those and I don't think you should be concerned
either.  The best attack possible is a brute force attack against the
password.

I use passwords that are as unguessable as I can make them.  They are
not going to hit the password by guessing.  They may be probing at the
ssh port.  But unless a vulnerability is found in ssh they cannot get
in without a valid password.

Trying to brute force the password would take way too many years to
complete.  The real world is not like the movies where crackers find
the password character by character and know those first characters.
(And in the movies that last character still takes the same amount of
time as the first. :-)

Bob



From sxw at inf.ed.ac.uk  Wed Jul  6 20:56:03 2005
From: sxw at inf.ed.ac.uk (sxw at inf.ed.ac.uk)
Date: Wed, 6 Jul 2005 11:56:03 +0100 (BST)
Subject: [PATCH] Simplify Kerberos credentials cache code
Message-ID: <Pine.LNX.4.44.0507061152570.31647-200000@hadrian.inf.ed.ac.uk>


The attached patch removes the duplicated credentials cache generation 
code in auth-krb5.c and gss-serv-krb5.c, by turning it into a procedure 
which is then called by both sections of code.

It's against the latest portable CVS tree.

Cheers,

Simon.
-------------- next part --------------
Index: auth-krb5.c
===================================================================
RCS file: /cvs/openssh/auth-krb5.c,v
retrieving revision 1.25
diff -u -r1.25 auth-krb5.c
--- auth-krb5.c	11 Sep 2004 13:32:09 -0000	1.25
+++ auth-krb5.c	6 Jul 2005 10:31:51 -0000
@@ -67,9 +67,6 @@
 #ifndef HEIMDAL
 	krb5_creds creds;
 	krb5_principal server;
-	char ccname[40];
-	int tmpfd;
-	mode_t old_umask;
 #endif
 	krb5_error_code problem;
 	krb5_ccache ccache = NULL;
@@ -146,28 +143,7 @@
 		goto out;
 	}
 
-	snprintf(ccname,sizeof(ccname),"FILE:/tmp/krb5cc_%d_XXXXXX",geteuid());
-
-	old_umask = umask(0177);
-	tmpfd = mkstemp(ccname + strlen("FILE:"));
-	umask(old_umask);
-	if (tmpfd == -1) {
-		logit("mkstemp(): %.100s", strerror(errno));
-		problem = errno;
-		goto out;
-	}
-
-	if (fchmod(tmpfd,S_IRUSR | S_IWUSR) == -1) {
-		logit("fchmod(): %.100s", strerror(errno));
-		close(tmpfd);
-		problem = errno;
-		goto out;
-	}
-	close(tmpfd);
-
-	problem = krb5_cc_resolve(authctxt->krb5_ctx, ccname, &authctxt->krb5_fwd_ccache);
-	if (problem)
-		goto out;
+	problem = ssh_krb5_cc_gen(authctxt->krb5_ctx, &authctxt->krb5_fwd_ccache);
 
 	problem = krb5_cc_initialize(authctxt->krb5_ctx, authctxt->krb5_fwd_ccache,
 				     authctxt->krb5_user);
@@ -234,4 +210,31 @@
 	}
 }
 
+#ifndef HEIMDAL
+krb5_error_code 
+ssh_krb5_cc_gen(krb5_context ctx, krb5_ccache *ccache) {
+	int tmpfd;
+	char ccname[40];
+	mode_t old_umask;
+
+	snprintf(ccname,sizeof(ccname),"FILE:/tmp/krb5cc_%d_XXXXXX",geteuid());
+
+	old_umask = umask(0177);
+	tmpfd = mkstemp(ccname + strlen("FILE:"));
+	umask(old_umask);
+	if (tmpfd == -1) {
+		logit("mkstemp(): %.100s", strerror(errno));
+		return errno;
+	}
+
+	if (fchmod(tmpfd,S_IRUSR | S_IWUSR) == -1) {
+		logit("fchmod(): %.100s", strerror(errno));
+		close(tmpfd);
+		return errno;
+	}
+	close(tmpfd);
+
+	return (krb5_cc_resolve(ctx, ccname, ccache));
+}
+#endif /* !HEIMDAL */
 #endif /* KRB5 */
Index: auth.h
===================================================================
RCS file: /cvs/openssh/auth.h,v
retrieving revision 1.67
diff -u -r1.67 auth.h
--- auth.h	16 Jun 2005 03:18:35 -0000	1.67
+++ auth.h	6 Jul 2005 10:31:51 -0000
@@ -191,4 +191,9 @@
 #define AUTH_FAIL_MSG "Too many authentication failures for %.100s"
 
 #define SKEY_PROMPT "\nS/Key Password: "
+
+#if defined(KRB5) && !defined(HEIMDAL)
+#include <krb5.h>
+krb5_error_code ssh_krb5_cc_gen(krb5_context, krb5_ccache *);
+#endif
 #endif
Index: gss-serv-krb5.c
===================================================================
RCS file: /cvs/openssh/gss-serv-krb5.c,v
retrieving revision 1.8
diff -u -r1.8 gss-serv-krb5.c
--- gss-serv-krb5.c	14 Aug 2004 13:55:38 -0000	1.8
+++ gss-serv-krb5.c	6 Jul 2005 10:31:51 -0000
@@ -131,34 +131,10 @@
 		return;
 	}
 #else
-	{
-		int tmpfd;
-		char ccname[40];
-		mode_t old_umask;
-
-		snprintf(ccname, sizeof(ccname),
-		    "FILE:/tmp/krb5cc_%d_XXXXXX", geteuid());
-
-		old_umask = umask(0177);
-		tmpfd = mkstemp(ccname + strlen("FILE:"));
-		umask(old_umask);
-		if (tmpfd == -1) {
-			logit("mkstemp(): %.100s", strerror(errno));
-			problem = errno;
-			return;
-		}
-		if (fchmod(tmpfd, S_IRUSR | S_IWUSR) == -1) {
-			logit("fchmod(): %.100s", strerror(errno));
-			close(tmpfd);
-			problem = errno;
-			return;
-		}
-		close(tmpfd);
-		if ((problem = krb5_cc_resolve(krb_context, ccname, &ccache))) {
-			logit("krb5_cc_resolve(): %.100s",
-			    krb5_get_err_text(krb_context, problem));
-			return;
-		}
+	if ((problem = ssh_krb5_cc_gen(krb_context, &ccache))) {
+		logit("ssh_krb5_cc_gen(): %.100s",
+		    krb5_get_err_text(krb_context, problem));
+		return;
 	}
 #endif	/* #ifdef HEIMDAL */
 

From lawrence.jones at ugs.com  Thu Jul  7 07:26:32 2005
From: lawrence.jones at ugs.com (Larry Jones)
Date: Wed, 6 Jul 2005 17:26:32 -0400 (EDT)
Subject: OpenSSH and non-blocking mode
Message-ID: <200507062126.j66LQWd04632@thor.net.plm.eds.com>

Dear OpenSSH developers,

OpenSSH setting non-blocking mode on its standard files creates serious
problems.

Setting non-blocking mode violates many of the semantics of how files
are supposed to behave and most programs (and most, if not all, stdio
libraries) are not prepared to deal with it.  That wouldn't be a problem
except that non-blocking mode is not a property of the file descriptor
but a property of the underlying file table entry and thus affects *all*
file descriptors that are bound to that file table entry, not just the
one used to set non-blocking mode.  Thus, you really shouldn't use
non-blocking mode unless you're in complete control of the underlying
file.  Since the standard files (stdin, stdout, and stderr) are
inherited from the parent process, that's never the case.  Consider:

	$ cat bigfile | wc -c
	 10858893
	$ (ssh localhost sleep 120& sleep 3; cat bigfile) | wc -c
	cat: stdout: Resource temporarily unavailable
	  270336

When ssh puts its stdout into non-blocking mode, it also puts cat's
stdout into non-blocking mode.  cat notices the problem, but doesn't
actually handle it correctly (most likely because it's using stdio and
thus *can't* handle it correctly), so the vast majority of the data just
disappears into the bit bucket.

I understand the necessity to keep ssh from blocking in order to keep
port-forwarding working, but wouldn't it be possible to do that by just
selecting for write before trying to write to stdout or stderr rather
than setting non-blocking mode?

-Larry Jones

My brain is trying to kill me. -- Calvin



From djm at mindrot.org  Thu Jul  7 09:49:30 2005
From: djm at mindrot.org (Damien Miller)
Date: Thu, 07 Jul 2005 09:49:30 +1000
Subject: OpenSSH and non-blocking mode
In-Reply-To: <200507062126.j66LQWd04632@thor.net.plm.eds.com>
References: <200507062126.j66LQWd04632@thor.net.plm.eds.com>
Message-ID: <42CC6E0A.5060700@mindrot.org>

Larry Jones wrote:
> Dear OpenSSH developers,
> 
> OpenSSH setting non-blocking mode on its standard files creates serious
> problems.

I don't think your analysis is correct: setting nonblock on one side of
a stdio connection shouldn't affect the other side (see the attached
test program).

> 	$ cat bigfile | wc -c
> 	 10858893
> 	$ (ssh localhost sleep 120& sleep 3; cat bigfile) | wc -c
> 	cat: stdout: Resource temporarily unavailable
> 	  270336

What platform are you using? This works fine on OpenBSD and Solaris.
You could be running into a kernel bug.

> I understand the necessity to keep ssh from blocking in order to keep
> port-forwarding working, but wouldn't it be possible to do that by just
> selecting for write before trying to write to stdout or stderr rather
> than setting non-blocking mode?

No - we cannot turn of non-blocking stdio in OpenSSH. select() will tell
you that a fd is ready for writing, but not how much data you can write.
So unless you are willing to do your IO one byte at a time,  select()ing
for each byte, you can still block.

-d
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: testnonblock.c
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20050707/97f35718/attachment.c 

From lawrence.jones at ugs.com  Thu Jul  7 10:25:02 2005
From: lawrence.jones at ugs.com (Larry Jones)
Date: Wed, 6 Jul 2005 20:25:02 -0400 (EDT)
Subject: OpenSSH and non-blocking mode
In-Reply-To: <42CC6E0A.5060700@mindrot.org> from "Damien Miller" at Jul 07,
	2005 09:49:30 AM
Message-ID: <200507070025.j670P2105126@thor.net.plm.eds.com>

Damien Miller writes:
> 
> I don't think your analysis is correct: setting nonblock on one side of
> a stdio connection shouldn't affect the other side (see the attached
> test program).

The problem isn't that setting nonblock on one end of a pipe (or
socketpair or pty) sets nonblock on the other end (which is what your
test progam test) -- it does not.  The problem is that other things can
be sharing the same end as ssh.  Look again at my example: 

	$ (ssh localhost sleep 120& sleep 3; cat bigfile) | wc -c

The problem is not that ssh setting nonblock affects wc on the other end
of the pipe, the problem is that it affects cat, which is sharing the
same end of the pipe for stdout as ssh since they both inherited them
from the same shell (they're also sharing the same stderr for the same
reason).

> What platform are you using? This works fine on OpenBSD and Solaris.
> You could be running into a kernel bug.

No, it's not a kernel bug.  I'm using BSD/OS, but I've had reports of
the problem on lots of other platforms.

> No - we cannot turn of non-blocking stdio in OpenSSH. select() will tell
> you that a fd is ready for writing, but not how much data you can write.

Drat.  I was thinking you'd get a partial write in that case, but you
only get partial writes in non-blocking mode.  Drat, drat, drat.

-Larry Jones

I've got more brains than I know what to do with. -- Calvin



From phil at usc.edu  Thu Jul  7 10:29:36 2005
From: phil at usc.edu (Phil Dibowitz)
Date: Wed, 6 Jul 2005 17:29:36 -0700
Subject: openssh and kerb 1.4.1 not so happy together
Message-ID: <20050707002935.GB27759@usc.edu>

Folks,

I seem to have a problem when I upgraded our kerberos from 1.3.1 to 1.4.1 (MIT
krb 5), all of a sudden I can't ssh as another user.

i.e.

ssh host

works but

ssh joe at host

doesn't work. Same with scp's.

I've tried recompiling ssh (even though the so-name of kerb libs didn't
change), but it didn't work, and still no go... I'm using openssh 3.9p1 on
Solaris 9 (and 8 and 2.6, but mostly 9) SPARC, and as I said MIT KerbV
1.4.1/1.3.1.

Anyone have any ideas?

-- 
Phil Dibowitz
Systems Architect and Administrator
Enterprise Infrastructure / ISD / USC
UCC 180 - 213-821-5427

-------------- 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/20050706/016d85c5/attachment.bin 

From sxw at inf.ed.ac.uk  Thu Jul  7 10:44:40 2005
From: sxw at inf.ed.ac.uk (sxw at inf.ed.ac.uk)
Date: Thu, 7 Jul 2005 01:44:40 +0100 (BST)
Subject: openssh and kerb 1.4.1 not so happy together
In-Reply-To: <20050707002935.GB27759@usc.edu>
Message-ID: <Pine.LNX.4.44.0507070140080.31647-100000@hadrian.inf.ed.ac.uk>

On Wed, 6 Jul 2005, Phil Dibowitz wrote:

> Folks,
> 
> I seem to have a problem when I upgraded our kerberos from 1.3.1 to 1.4.1 (MIT
> krb 5), all of a sudden I can't ssh as another user.

Do you have tickets on the client? Are they for you, or for 'joe'?

Are you expecting logging in as 'joe' to succeed due to a .k5login file, 
or should you be prompted for a password?

What are you using for Kerberos password authentication? PAM, or the 
inbuilt KerberosAuthentication stuff?

Does the server fail cleanly, or does it die?

Can you provide debugging logs from the client (with -v -v) and from the 
server (-d -d -d)?

Cheers,

Simon.



From phil at usc.edu  Thu Jul  7 11:05:14 2005
From: phil at usc.edu (Phil Dibowitz)
Date: Wed, 6 Jul 2005 18:05:14 -0700
Subject: openssh and kerb 1.4.1 not so happy together
In-Reply-To: <Pine.LNX.4.44.0507070140080.31647-100000@hadrian.inf.ed.ac.uk>
References: <20050707002935.GB27759@usc.edu>
	<Pine.LNX.4.44.0507070140080.31647-100000@hadrian.inf.ed.ac.uk>
Message-ID: <20050707010514.GG27759@usc.edu>

On Thu, Jul 07, 2005 at 01:44:40AM +0100, sxw at inf.ed.ac.uk wrote:
> On Wed, 6 Jul 2005, Phil Dibowitz wrote:
> 
> > Folks,
> > 
> > I seem to have a problem when I upgraded our kerberos from 1.3.1 to 1.4.1 (MIT
> > krb 5), all of a sudden I can't ssh as another user.
> 
> Do you have tickets on the client? Are they for you, or for 'joe'?

no, no.

> Are you expecting logging in as 'joe' to succeed due to a .k5login file, 
> or should you be prompted for a password?

I expect a password prompt, and I get one. I then says "connection closed by:
<ip of server>"

> What are you using for Kerberos password authentication? PAM, or the 
> inbuilt KerberosAuthentication stuff?

builtin gssapi stuff so people have the OPTION of kinit'ing for passwordless
login, but can use keys or password if they chose.

> Does the server fail cleanly, or does it die?

See above.

> Can you provide debugging logs from the client (with -v -v) and from the 
> server (-d -d -d)?

Sure, I should have done that before. ::slaps own wrist:: sorry.

Turns out that makes the error clear:

ld.so.1: /usr/lsd/openssh/default/sbin/sshd: fatal: relocation error: file
/usr/lsd/openssh/default/sbin/sshd: symbol krb5_init_ets: referenced symbol
not found
Killed

Of course, that's not the recompiled version.... but the recompiled version
has the same external symptoms. Hmmm.

-- 
Phil Dibowitz
Systems Architect and Administrator
Enterprise Infrastructure / ISD / USC
UCC 180 - 213-821-5427

-------------- 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/20050706/a2b18a66/attachment.bin 

From djm at mindrot.org  Thu Jul  7 11:44:41 2005
From: djm at mindrot.org (Damien Miller)
Date: Thu, 07 Jul 2005 11:44:41 +1000
Subject: openssh and kerb 1.4.1 not so happy together
In-Reply-To: <20050707002935.GB27759@usc.edu>
References: <20050707002935.GB27759@usc.edu>
Message-ID: <42CC8909.6070801@mindrot.org>

Phil Dibowitz wrote:
> Folks,
> 
> I seem to have a problem when I upgraded our kerberos from 1.3.1 to 1.4.1 (MIT
> krb 5), all of a sudden I can't ssh as another user.
> 
> i.e.
> 
> ssh host
> 
> works but
> 
> ssh joe at host
> 
> doesn't work. Same with scp's.
...
> Anyone have any ideas?

yes, how about posting a debug trace so we can see what "doesn't work"
really means.

-d



From sxw at inf.ed.ac.uk  Thu Jul  7 19:20:29 2005
From: sxw at inf.ed.ac.uk (sxw at inf.ed.ac.uk)
Date: Thu, 7 Jul 2005 10:20:29 +0100 (BST)
Subject: openssh and kerb 1.4.1 not so happy together
In-Reply-To: <20050707010514.GG27759@usc.edu>
Message-ID: <Pine.LNX.4.44.0507071017330.31647-100000@hadrian.inf.ed.ac.uk>

On Wed, 6 Jul 2005, Phil Dibowitz wrote:

> Turns out that makes the error clear:
> 
> ld.so.1: /usr/lsd/openssh/default/sbin/sshd: fatal: relocation error: file
> /usr/lsd/openssh/default/sbin/sshd: symbol krb5_init_ets: referenced symbol
> not found
> Killed
> 
> Of course, that's not the recompiled version.... but the recompiled version
> has the same external symptoms. Hmmm.

You need to do a make distclean, and then re-run ./configure. I would 
imagine that the soname didn't change because krb5_init_ets isn't part of 
MIT's officially exported API.

We should probably just pull the call to krb5_init_ets - its been years 
since any version of Kerberos required it.

S.



From bushman at rsu.ru  Thu Jul  7 22:38:55 2005
From: bushman at rsu.ru (Michael Bushkov)
Date: Thu, 07 Jul 2005 16:38:55 +0400
Subject: openssh and nsswitch integration in FreeBSD
Message-ID: <42CD225F.8030305@rsu.ru>

Hello!
I'm working on openssh and nsswitch integration in FreeBSD. I am lucky 
to participate in Googles' Summer of  Code and openssh+nsswitch 
integration is the part of my project. I've almost completed the patch. 
I'd like to describe some details here. I'll be glad to correct or 
change some things if you wish.

The idea is to replace system-wide known-hosts file with nsswitch source.
After examining openssh port, I've found 2 basic functions, which handle 
the known-hosts files (hostfile.h):

HostStatus check_host_in_hostfile(const char *, const char *, const Key 
*, Key *, int *);
int    lookup_key_in_hostfile_by_type(const char *, const char *, int, 
Key *, int *);

As far as I know, all other routines, that deal with these files are 
seem to be built on top of these 2 functions. So I'd like to implement 
another 2 functions:
HostStatus nsswitch_check_host(const char *, const Key *, Key *);
int    nsswitch_lookup_key_by_type(const char *, int, Key *);

They will be used instead of previous 2 in all places, where system-wide 
known-hosts file was accessed. But it will dispatch the calls to the 
nsswitch subsystem. Nsswitch 'files' module will have the same 
functionality as the previous 2 functions, but users will be able to 
store their public keys in LDAP, for example. Besides any other source 
can be implemented as the pluggable nsswitch module.

In ssh client the files module will take the system files path from the 
Options structure. And in the sshd (in case of hostbased 
authentication), it will use the default values.

So this is the way I want to integrate nsswitch and openssh in FreeBSD. 
Is this approach applicable?

With best regards,
Michael Bushkov
Rostov State University




From phil at usc.edu  Fri Jul  8 06:02:05 2005
From: phil at usc.edu (Phil Dibowitz)
Date: Thu, 7 Jul 2005 13:02:05 -0700
Subject: openssh and kerb 1.4.1 not so happy together
In-Reply-To: <Pine.LNX.4.44.0507071017330.31647-100000@hadrian.inf.ed.ac.uk>
References: <20050707010514.GG27759@usc.edu>
	<Pine.LNX.4.44.0507071017330.31647-100000@hadrian.inf.ed.ac.uk>
Message-ID: <20050707200205.GH8907@usc.edu>

On Thu, Jul 07, 2005 at 10:20:29AM +0100, sxw at inf.ed.ac.uk wrote:
> On Wed, 6 Jul 2005, Phil Dibowitz wrote:
> 
> > Turns out that makes the error clear:
> > 
> > ld.so.1: /usr/lsd/openssh/default/sbin/sshd: fatal: relocation error: file
> > /usr/lsd/openssh/default/sbin/sshd: symbol krb5_init_ets: referenced symbol
> > not found
> > Killed
> > 
> > Of course, that's not the recompiled version.... but the recompiled version
> > has the same external symptoms. Hmmm.
> 
> You need to do a make distclean, and then re-run ./configure. I would 
> imagine that the soname didn't change because krb5_init_ets isn't part of 
> MIT's officially exported API.
> 
> We should probably just pull the call to krb5_init_ets - its been years 
> since any version of Kerberos required it.

Tried that, same symptom, different problem. the sshd -ddd gives:

Assertion failed: i->did_run != 0, file
../../../../src/lib/krb5/../../include/k5-pla
tform.h, line 232

Or more specifically:

[root at ain etc]# /usr/lsd/openssh/default/sbin/sshd -d -d -d -p 1022
debug2: load_server_config: filename /etc/ssh/sshd_config
debug2: load_server_config: done config len = 367
debug2: parse_server_config: config /etc/ssh/sshd_config len 367
debug1: sshd version OpenSSH_3.9p1
debug1: private host key: #0 type 0 RSA1
debug3: Not a RSA1 key file /etc/ssh/ssh_host_rsa_key.
debug1: read PEM private key done: type RSA
debug1: private host key: #1 type 1 RSA
debug3: Not a RSA1 key file /etc/ssh/ssh_host_dsa_key.
debug1: read PEM private key done: type DSA
debug1: private host key: #2 type 2 DSA
debug1: rexec_argv[0]='/usr/lsd/openssh/default/sbin/sshd'
debug1: rexec_argv[1]='-d'
debug1: rexec_argv[2]='-d'
debug1: rexec_argv[3]='-d'
debug1: rexec_argv[4]='-p'
debug1: rexec_argv[5]='1022'
debug2: fd 4 setting O_NONBLOCK
debug1: Bind to port 1022 on 0.0.0.0.
Server listening on 0.0.0.0 port 1022.
Generating 768 bit RSA key.
RSA key generation complete.
debug1: fd 5 clearing O_NONBLOCK
debug1: Server will not fork when running in debugging mode.
debug3: send_rexec_state: entering fd = 10 config len 367
debug3: ssh_msg_send: type 0
debug3: send_rexec_state: done
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 10
Assertion failed: i->did_run != 0, file
../../../../src/lib/krb5/../../include/k5-platform.h, line 232
Abort
[root at ain etc]# 

For reference the area around line 232 in k5-platform.h in krb5 1.4.1 is:

static inline int k5_call_init_function(k5_init_t *i)
{
    int err;
    err = k5_once(&i->once, i->fn);
    if (err)
        return err;
    assert (i->did_run != 0);
    return i->error;
}


-- 
Phil Dibowitz
Systems Architect and Administrator
Enterprise Infrastructure / ISD / USC
UCC 180 - 213-821-5427

-------------- 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/20050707/ef919f6a/attachment.bin 

From phil at usc.edu  Fri Jul  8 07:43:10 2005
From: phil at usc.edu (Phil Dibowitz)
Date: Thu, 7 Jul 2005 14:43:10 -0700
Subject: openssh and kerb 1.4.1 not so happy together
In-Reply-To: <20050707200205.GH8907@usc.edu>
References: <20050707010514.GG27759@usc.edu>
	<Pine.LNX.4.44.0507071017330.31647-100000@hadrian.inf.ed.ac.uk>
	<20050707200205.GH8907@usc.edu>
Message-ID: <20050707214309.GO8907@usc.edu>

On Thu, Jul 07, 2005 at 01:02:05PM -0700, Phil Dibowitz wrote:
> On Thu, Jul 07, 2005 at 10:20:29AM +0100, sxw at inf.ed.ac.uk wrote:
> > On Wed, 6 Jul 2005, Phil Dibowitz wrote:
> > 
> > > Turns out that makes the error clear:
> > > 
> > > ld.so.1: /usr/lsd/openssh/default/sbin/sshd: fatal: relocation error: file
> > > /usr/lsd/openssh/default/sbin/sshd: symbol krb5_init_ets: referenced symbol
> > > not found
> > > Killed
> > > 
> > > Of course, that's not the recompiled version.... but the recompiled version
> > > has the same external symptoms. Hmmm.
> > 
> > You need to do a make distclean, and then re-run ./configure. I would 
> > imagine that the soname didn't change because krb5_init_ets isn't part of 
> > MIT's officially exported API.
> > 
> > We should probably just pull the call to krb5_init_ets - its been years 
> > since any version of Kerberos required it.
> 
> Tried that, same symptom, different problem. the sshd -ddd gives:
> 
> Assertion failed: i->did_run != 0, file
> ../../../../src/lib/krb5/../../include/k5-pla
> tform.h, line 232

OK, well this isn't entirely accurate.

The full recompile with make distclean fixes Solaris 8 and Solaris 9 machines.
I only get the above on Solaris 2.6.

Further, I get it in other apps as well.

Which leads me to believe it's a kerb issue. I'll drop them an email. Thanks.

-- 
Phil Dibowitz
Systems Architect and Administrator
Enterprise Infrastructure / ISD / USC
UCC 180 - 213-821-5427

-------------- 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/20050707/33db0705/attachment.bin 

From jg at jguk.org  Mon Jul 11 01:51:00 2005
From: jg at jguk.org (J. Grant)
Date: Sun, 10 Jul 2005 16:51:00 +0100
Subject: sftp backspace not working (OpenSSH_3.8.1p1 Debian-8.sarge.4)
Message-ID: <42D143E4.9010305@jguk.org>

I am using sftp which comes with OpenSSH_3.8.1p1 Debian-8.sarge.4,
OpenSSL 0.9.7e 25 Oct 2004

I noticed backspace is not working. Couild someone tell me if this is
fixed in a newer package please?

Also, would it be possible for sftp --version to be implemented? also
sftp --V.  Likewise ssh --version is not implemented either.  None of
the flags are listed when i type ssh --help, or sftp --help

Kind regards
JG
-- 
Homepage: http://jguk.org/
Blog: http://jguk.org/blog.rss
Radio: http://jguk.org/#radio



From OpenMacNews at speakeasy.net  Mon Jul 11 04:58:53 2005
From: OpenMacNews at speakeasy.net (OpenMacNews)
Date: Sun, 10 Jul 2005 11:58:53 -0700
Subject: openssh-4.1p1 on OSX 10.4.1 w/  openssl-0.9.8 NOT FINDING -lcrypto
Message-ID: <E5CEB755ED4DE3D22B7E0943@tiedgar>

hi all,

building on OSX 10.4.1, with a prereq of:

% which openssl
	/usr/local/ssl/bin/openssl
% openssl version
	OpenSSL 0.9.8 05 Jul 2005

building either openssh-4.0p1 or openssh-4.1p1 on OSX 10.4.1, w/:

	./configure --with-ssl-dir=/usr/local/ssl

configure fails w/:

	...
	checking whether getpgrp requires zero arguments... yes
	checking OpenSSL header version... not found
	configure: error: OpenSSL version header not found.

popping up a dialog of:

	Link (dyld) error:
	
	Library not loaded: libcrypto.0.9.8.dylib
	  Referenced from: /usr/ports/openssh-4.1p1/./conftest
	  Reason: image not found

my config.log reports:

	configure:13736: gcc -o conftest -g -O2 -Wall -Wpointer-arith 
-Wno-uninitialized -I/usr/local/ssl/include  -L/usr/local/ssl/lib  conftest.c 
-lcrypto -lz  >&5
	configure:13742: $? = 0
	configure:13746: test -z
							 || test ! -s conftest.err
	configure:13749: $? = 0
	configure:13752: test -s conftest
	configure:13755: $? = 0
	configure:13840: checking OpenSSL header version
	configure:13876: gcc -o conftest -g -O2 -Wall -Wpointer-arith 
-Wno-uninitialized -I/usr/local/ssl/include  -L/usr/local/ssl/lib  conftest.c 
-lcrypto -lz  >&5
	conftest.c: In function 'main':
	conftest.c:151: warning: implicit declaration of function 'exit'
	conftest.c:151: warning: incompatible implicit declaration of built-in 
function 'exit'
	conftest.c:153: warning: format '%x' expects type 'unsigned int', but argument 
3 has type 'long int'
	configure:13879: $? = 0
	configure:13881: ./conftest
	dyld: Library not loaded: libcrypto.0.9.8.dylib
	  Referenced from: /usr/ports/openssh-4.0p1/./conftest
	  Reason: image not found
	./configure: line 1: 15872 Trace/BPT trap          ./conftest$ac_exeext
	configure:13884: $? = 133
	configure: program exited with status 133
	configure: failed program was:
	| /* confdefs.h.  */
	|

per above, it's complaining about:

	dyld: Library not loaded: libcrypto.0.9.8.dylib
	...
	Reason: image not found

which *is* in place @:

	ls -al /usr/local/ssl/lib/libcrypto.0.9.8.dylib
		-r-xr-xr-x  1 root staff 1412444 Jul 10 10:46 
/usr/local/ssl/lib/libcrypto.0.9.8.dylib


so, i suspect it may be an issue in "contrib/findssl.sh", not picking up *MY* 
ssl path, but dunno as yet ....

comments? thoughts?

cheers,

richard



From OpenMacNews at speakeasy.net  Mon Jul 11 07:15:39 2005
From: OpenMacNews at speakeasy.net (OpenMacNews)
Date: Sun, 10 Jul 2005 14:15:39 -0700
Subject: [RESOLVED, in 'findssl.sh'] Re: openssh-4.1p1 on OSX 10.4.1 w/ 
	openssl-0.9.8 NOT FINDING -lcrypto
Message-ID: <8ABA566F012B15851A249C1F@tiedgar>

hi all,

> configure fails w/:
>
> 	...
> 	checking whether getpgrp requires zero arguments... yes
> 	checking OpenSSL header version... not found
> 	configure: error: OpenSSL version header not found.

i first suspected the 'culprit' to be the following stanza in 
"contrib/findssl.sh":

	...
	echo Searching for OpenSSL header files.
	if [ -x "`which locate`" ]
	then
		headers=`locate opensslv.h`
	else
		headers=`find / -name opensslv.h -print 2>/dev/null`
	fi
	...
    for header in $headers
    do
        ver=`awk '/OPENSSL_VERSION_NUMBER/{printf \$3}' $header`
    ...

though it is, in my own experience, uncommon to use 'locate', rather than 
simply traversing the def'd ENV path and checking for existence of the file(s) 
in question, given that i *do* have a 'locate' on OSX, it'll obviously search 
for opensslv.h ...

on my 'errant' system, checking:

	% locate opensslv.h
		/usr/include/openssl/opensslv.h
		/Developer/SDKs/MacOSX10.3.9.sdk/usr/include/openssl/opensslv.h
		/Developer/SDKs/MacOSX10.4.0.sdk/usr/include/openssl/opensslv.h
		/Developer/SDKs/MacOSX10.4u.sdk/usr/include/openssl/opensslv.h
		/usr/include/openssl/opensslv.h
		/usr/ports/openssl-0.9.7g/crypto/opensslv.h
		/usr/ports/openssl-0.9.7g/include/openssl/opensslv.h
		/usr/local/ssl/include/openssl/opensslv.h


its finding /usr/local/ssl/include/openssl/opensslv.h where it should ... just 
'late' in the result.

as it's not immediately clear to me how to CHANGE that locate result search 
path ... iiuc, it seems that the env var DEFAULT_LIBPATH may be the key ...

so, setting:

	setenv DEFAULT_LIBPATH "(stuff):/usr/local/ssl/lib:( ... before 
...):/usr/lib:(... more stuff ...)"

to override findssl.sh's 'internal':

	#
	# Set default library paths if not already set
	#
	DEFAULT_LIBPATH=/usr/lib:/usr/local/lib

and checking: configure, make & install are all, now, OK, resulting in:

    which ssh
    	/usr/local/openssh/bin/ssh
    ssh -V
    	OpenSSH_4.1p1, OpenSSL 0.9.8 05 Jul 2005
    otool -L /usr/local/openssh/bin/ssh
        /usr/local/openssh/bin/ssh:
            libcrypto.0.9.8.dylib (compatibility version 0.9.8, current version 
0.9.8)
            /usr/local/lib/libz.1.2.2.dylib (compatibility version 1.2.0, 
current version 1.2.2)
            /usr/lib/libmx.A.dylib (compatibility version 1.0.0, current 
version 92.0.0)
            /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 88.0.0)

so, it seems to me that, in addition to, or for that matter -- inspite of,

    ./configure \
    ...
    --with-ssl-dir=/usr/local/ssl \
    --with-ldflags="-L/usr/local/ssl/lib" \
    --with-cppflags="-I/usr/local/ssl/include" \
    ...

findssl.sh ALSO needs the ENV var set.

imho, it would be nice if it picked up the 'right' loc'n from the cmd line ... 
preferably JUST from the " --with-ssl-dir" spec'n ...

cheers,

richard





From djm at mindrot.org  Mon Jul 11 09:55:52 2005
From: djm at mindrot.org (Damien Miller)
Date: Mon, 11 Jul 2005 09:55:52 +1000
Subject: sftp backspace not working (OpenSSH_3.8.1p1 Debian-8.sarge.4)
In-Reply-To: <42D143E4.9010305@jguk.org>
References: <42D143E4.9010305@jguk.org>
Message-ID: <42D1B588.3020702@mindrot.org>

J. Grant wrote:
> I am using sftp which comes with OpenSSH_3.8.1p1 Debian-8.sarge.4,
> OpenSSL 0.9.7e 25 Oct 2004
> 
> I noticed backspace is not working. Couild someone tell me if this is
> fixed in a newer package please?

Why don't you ask the Debian maintainer - this is a very
distribution-specific problem.

> Also, would it be possible for sftp --version to be implemented? also
> sftp --V.  Likewise ssh --version is not implemented either.  None of
> the flags are listed when i type ssh --help, or sftp --help

No, we don't do --gnu-long-options.

-d



From dtucker at zip.com.au  Mon Jul 11 11:09:54 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Mon, 11 Jul 2005 11:09:54 +1000
Subject: openssh-4.1p1 on OSX 10.4.1 w/ openssl-0.9.8 NOT FINDING -lcrypto
In-Reply-To: <E5CEB755ED4DE3D22B7E0943@tiedgar>
References: <E5CEB755ED4DE3D22B7E0943@tiedgar>
Message-ID: <42D1C6E2.4000502@zip.com.au>

OpenMacNews wrote:
> hi all,
> 
> building on OSX 10.4.1, with a prereq of:
> 
> % which openssl
> 	/usr/local/ssl/bin/openssl
> % openssl version
> 	OpenSSL 0.9.8 05 Jul 2005
> 
> building either openssh-4.0p1 or openssh-4.1p1 on OSX 10.4.1, w/:
> 
> 	./configure --with-ssl-dir=/usr/local/ssl
> 
> configure fails w/:
> 
> 	...
> 	checking whether getpgrp requires zero arguments... yes
> 	checking OpenSSL header version... not found
> 	configure: error: OpenSSL version header not found.
> 
> popping up a dialog of:
> 
> 	Link (dyld) error:
> 	
> 	Library not loaded: libcrypto.0.9.8.dylib
> 	  Referenced from: /usr/ports/openssh-4.1p1/./conftest
> 	  Reason: image not found

I don't know OS X but on other platforms that kind of error would 
indicate that /usr/local/ssl/lib was not in the run-time link path (ie 
LD_LIBRARY_PATH or LIBPATH depending on the platform).

If your runtime linker supports "-R" then you can use it too 
("./configure --with-rpath").

[...]
> so, i suspect it may be an issue in "contrib/findssl.sh", not picking up *MY* 
> ssl path, but dunno as yet ....

No, findssl.sh isn't part of the build process, it's merely a 
supplemental tool to show what OpenSSL versions you have installed. 
(Reports of "your OpenSSL headers do not match your library" errors used 
to be common, and it's to help diagnose those.)

-- 
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 OpenMacNews at speakeasy.net  Mon Jul 11 11:48:07 2005
From: OpenMacNews at speakeasy.net (OpenMacNews)
Date: Sun, 10 Jul 2005 18:48:07 -0700
Subject: openssh-4.1p1 on OSX 10.4.1 w/ openssl-0.9.8 NOT FINDING -lcrypto
In-Reply-To: <42D1C6E2.4000502@zip.com.au>
References: <E5CEB755ED4DE3D22B7E0943@tiedgar> <42D1C6E2.4000502@zip.com.au>
Message-ID: <E0ECC339C98F59F381F023FD@tiedgar>

hi darren,

thx! for the reply =)

> No, findssl.sh isn't part of the build process, it's merely a
> supplemental tool to show what OpenSSL versions you have installed.

if that's in fact the case ... then i simply 'got ;ucky' (as per my SUBSEQUENT 
post ...) with the:

    setenv DEFAULT_LIBPATH

clearly, it makes the difference ... but, apparently, not in findssl.sh ... and,

> ... /usr/local/ssl/lib was not in the run-time link path (ie
> LD_LIBRARY_PATH or LIBPATH depending on the platform)

IS the issue ...

odd that it's never been an issue for me before, as long as LDFLAGS/CPPFLAGS 
have been properly set.

cheers,

richard



From dtucker at zip.com.au  Mon Jul 11 12:11:32 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Mon, 11 Jul 2005 12:11:32 +1000
Subject: openssh-4.1p1 on OSX 10.4.1 w/ openssl-0.9.8 NOT FINDING -lcrypto
In-Reply-To: <E0ECC339C98F59F381F023FD@tiedgar>
References: <E5CEB755ED4DE3D22B7E0943@tiedgar> <42D1C6E2.4000502@zip.com.au>
	<E0ECC339C98F59F381F023FD@tiedgar>
Message-ID: <42D1D554.5060804@zip.com.au>

OpenMacNews wrote:
>    setenv DEFAULT_LIBPATH
> 
> clearly, it makes the difference ... but, apparently, not in findssl.sh 

If you unset those variables do the binaries stop working?

>> ... /usr/local/ssl/lib was not in the run-time link path (ie
>> LD_LIBRARY_PATH or LIBPATH depending on the platform)
> 
> 
> IS the issue ...
> 
> odd that it's never been an issue for me before, as long as 
> LDFLAGS/CPPFLAGS have been properly set.

If you were using either the system's libcrypto or linking against a 
static libcrypto (the latter being the default for at least OpenSSL 
0.9.7g and below) then the run-time linker path is not going to be an issue.

BTW findssl.sh uses "locate" when available because it's much faster 
than "find".

-- 
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 OpenMacNews at speakeasy.net  Mon Jul 11 12:22:48 2005
From: OpenMacNews at speakeasy.net (OpenMacNews)
Date: Sun, 10 Jul 2005 19:22:48 -0700
Subject: openssh-4.1p1 on OSX 10.4.1 w/ openssl-0.9.8 NOT FINDING -lcrypto
In-Reply-To: <42D1D554.5060804@zip.com.au>
References: <E5CEB755ED4DE3D22B7E0943@tiedgar>
	<42D1C6E2.4000502@zip.com.au>	<E0ECC339C98F59F381F023FD@tiedgar>
	<42D1D554.5060804@zip.com.au>
Message-ID: <D769A87D84A74513407B3DFF@tiedgar>

hi darren,

>>    setenv DEFAULT_LIBPATH
>>
>> clearly, it makes the difference ... but, apparently, not in findssl.sh
>
> If you unset those variables do the binaries stop working?

nope.  if I:

    setenv DEFAULT_LIBPATH

built binaries are all still ok ... i just can't compile/link fresh with it 
UNset.

>> odd that it's never been an issue for me before, as long as
>> LDFLAGS/CPPFLAGS have been properly set.
>
> If you were using either the system's libcrypto

i'm not ...

> or linking against a
> static libcrypto (the latter being the default for at least OpenSSL
> 0.9.7g and below) then the run-time linker path is not going to be an issue.

ok. hmmm ... it may be worth mentioning, then, that in my/this case, i've built 
openssl (OpenSSL 0.9.8 05 Jul 2005) as:

    ./Configure --prefix=/usr/local/ssl --openssldir=/usr/local/ssl 
darwin-ppc-cc -DUSE_TOD shared threads enable-rc5 enable-mdc2 -DOPENSSL_USE_GMP 
-lgmp

with:

% ls -al /usr/local/ssl/lib/
    total 4608
    drwxr-xr-x  12 root staff     408 Jul 10 10:46 .
    drwxr-xr-x  10 root staff     340 Jul 10 10:46 ..
    drwxr-xr-x  11 root staff     374 Jul 10 10:46 engines
    -r-xr-xr-x   1 root staff 1412444 Jul 10 10:46 libcrypto.0.9.8.dylib
    lrwxr-xr-x   1 root staff      21 Jul 10 10:17 libcrypto.0.9.dylib ->
    libcrypto.0.9.8.dylib
    -rw-r--r--   1 root staff 2507608 Jul 10 10:46 libcrypto.a
    lrwxr-xr-x   1 root staff      21 Jul 10 10:46 libcrypto.dylib ->
    libcrypto.0.9.8.dylib
    -r-xr-xr-x   1 root staff  309744 Jul 10 10:46 libssl.0.9.8.dylib
    lrwxr-xr-x   1 root staff      18 Jul 10 10:17 libssl.0.9.dylib ->
    libssl.0.9.8.dylib
    -rw-r--r--   1 root staff  463136 Jul 10 10:46 libssl.a
    lrwxr-xr-x   1 root staff      18 Jul 10 10:46 libssl.dylib ->
    libssl.0.9.8.dylib
    drwxr-xr-x   5 root staff     170 Jul 10 10:00 pkgconfig

> BTW findssl.sh uses "locate" when available because it's much faster than 
"find".

ok. agreed that its faster  .... just curious if/how its path traversal differs 
...

cheers,

richard



From dtucker at zip.com.au  Mon Jul 11 12:31:51 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Mon, 11 Jul 2005 12:31:51 +1000
Subject: openssh-4.1p1 on OSX 10.4.1 w/ openssl-0.9.8 NOT FINDING -lcrypto
In-Reply-To: <D769A87D84A74513407B3DFF@tiedgar>
References: <E5CEB755ED4DE3D22B7E0943@tiedgar>
	<42D1C6E2.4000502@zip.com.au>	<E0ECC339C98F59F381F023FD@tiedgar>
	<42D1D554.5060804@zip.com.au> <D769A87D84A74513407B3DFF@tiedgar>
Message-ID: <42D1DA17.9050806@zip.com.au>

OpenMacNews wrote:
>    setenv DEFAULT_LIBPATH
> 
> built binaries are all still ok ... i just can't compile/link fresh with 
> it UNset.

In that case I suspect DEFAULT_LIBPATH is magic to the OS X linker and 
you were just lucky :-)

> ok. hmmm ... it may be worth mentioning, then, that in my/this case, 
> i've built openssl (OpenSSL 0.9.8 05 Jul 2005) as:
> 
>    ./Configure --prefix=/usr/local/ssl --openssldir=/usr/local/ssl 
> darwin-ppc-cc -DUSE_TOD shared threads enable-rc5 enable-mdc2 
> -DOPENSSL_USE_GMP -lgmp

It looks like the "shared" option is the reason.  If you were to rebuild 
w/out it (and delete the existing libaries from /usr/local/ssl/lib) then 
I strongly suspect you will not see the problem.

>> BTW findssl.sh uses "locate" when available because it's much faster than 
>> "find".
> 
> ok. agreed that its faster  .... just curious if/how its path traversal 
> differs ...

It doesn't matter.  findssl.sh's purpose is to show *all* installed 
versions, the order is irrelevant.

-- 
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 OpenMacNews at speakeasy.net  Mon Jul 11 12:37:15 2005
From: OpenMacNews at speakeasy.net (OpenMacNews)
Date: Sun, 10 Jul 2005 19:37:15 -0700
Subject: openssh-4.1p1 on OSX 10.4.1 w/ openssl-0.9.8 NOT FINDING -lcrypto
In-Reply-To: <42D1DA17.9050806@zip.com.au>
References: <E5CEB755ED4DE3D22B7E0943@tiedgar>	<42D1C6E2.4000502@zip.com.au>
	<E0ECC339C98F59F381F023FD@tiedgar>	<42D1D554.5060804@zip.com.au>
	<D769A87D84A74513407B3DFF@tiedgar> <42D1DA17.9050806@zip.com.au>
Message-ID: <DC6FCCA66B39CC644FC3EFE2@tiedgar>

hi,

>> built binaries are all still ok ... i just can't compile/link fresh with
>> it UNset.
>
> In that case I suspect DEFAULT_LIBPATH is magic to the OS X linker and
> you were just lucky :-)

i HATE when that happens! ;-P

>>    ./Configure --prefix=/usr/local/ssl --openssldir=/usr/local/ssl
>> darwin-ppc-cc -DUSE_TOD shared threads enable-rc5 enable-mdc2
>> -DOPENSSL_USE_GMP -lgmp
>
> It looks like the "shared" option is the reason.  If you were to rebuild
> w/out it (and delete the existing libaries from /usr/local/ssl/lib) then
> I strongly suspect you will not see the problem.

makes sense.  tho, i've been building 'shared' for ages, w/ no such issues ... 
i love gremlies, don't you !?

> It doesn't matter.  findssl.sh's purpose is to show *all* installed
> versions, the order is irrelevant.

clear.

thx! again.

onward ...

richard

> Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

heh, amen!



From OpenMacNews at speakeasy.net  Mon Jul 11 12:45:18 2005
From: OpenMacNews at speakeasy.net (OpenMacNews)
Date: Sun, 10 Jul 2005 19:45:18 -0700
Subject: openssh-4.1p1 on OSX 10.4.1 w/ openssl-0.9.8 NOT FINDING -lcrypto
In-Reply-To: <DC6FCCA66B39CC644FC3EFE2@tiedgar>
References: <E5CEB755ED4DE3D22B7E0943@tiedgar>	<42D1C6E2.4000502@zip.com.au>
	<E0ECC339C98F59F381F023FD@tiedgar>	<42D1D554.5060804@zip.com.au>
	<D769A87D84A74513407B3DFF@tiedgar> <42D1DA17.9050806@zip.com.au>
	<DC6FCCA66B39CC644FC3EFE2@tiedgar>
Message-ID: <530D081B391E1DB265E50266@tiedgar>

ack!

    s/gremlies/gremlins/g

r



From OpenMacNews at speakeasy.net  Tue Jul 12 18:16:18 2005
From: OpenMacNews at speakeasy.net (OpenMacNews)
Date: Tue, 12 Jul 2005 01:16:18 -0700
Subject: openssh-4.1p1 on OSX 10.4.1 w/ openssl-0.9.8 NOT FINDING -lcrypto
In-Reply-To: <42D1DA17.9050806@zip.com.au>
References: <E5CEB755ED4DE3D22B7E0943@tiedgar>
	<42D1C6E2.4000502@zip.com.au>	<E0ECC339C98F59F381F023FD@tiedgar>
	<42D1D554.5060804@zip.com.au> <D769A87D84A74513407B3DFF@tiedgar>
	<42D1DA17.9050806@zip.com.au>
Message-ID: <1F2EE9F0FD39A3E0575AA94E@tiedgar>

hi darren,

> It looks like the "shared" option is the reason.  If you were to rebuild
> w/out it (and delete the existing libaries from /usr/local/ssl/lib) then I
> strongly suspect you will not see the problem.

unfortunately, trying to build w/ static ssl/zlib on OSX opens up "a whole 
nother can o worms" ... <sigh> ...

> It doesn't matter.  findssl.sh's purpose is to show *all* installed versions,
> the order is irrelevant.


anyway, a question re: findssl.sh ...

after an update of my local locate DB, i find:

% ls -al /usr/local/lib/libcrypto*
    -r-xr-xr-x  1 root staff 1413064 Jul 11 23:55 
/usr/local/lib/libcrypto.0.9.8.dylib
    -rw-r--r--  1 root staff 2510832 Jul 11 23:55 /usr/local/lib/libcrypto.a
    lrwxr-xr-x  1 root staff      21 Jul 11 23:55 
/usr/local/lib/libcrypto.dylib -> libcrypto.0.9.8.dylib

and,

% locate libcrypto.a
    /Volumes/SystemFiles/local/lib/libcrypto.a
    /Volumes/SystemFiles/local/tempstatic/lib/libcrypto.a

where,

% ls -ald /usr/local
    lrwxr-xr-x  1 root wheel 26 Jun 12 12:40 /usr/local -> 
/Volumes/SystemFiles/local

but,

    % sh /usr/ports/openssh-4.1p1/contrib/findssl.sh
        Searching for OpenSSL header files.
        0x0090702fL /usr/include/openssl/opensslv.h
        0x0090702fL
        /Developer/SDKs/MacOSX10.3.9.sdk/usr/include/openssl/opensslv.h
        0x0090702fL
        /Developer/SDKs/MacOSX10.4.0.sdk/usr/include/openssl/opensslv.h
        0x0090702fL
        /Developer/SDKs/MacOSX10.4u.sdk/usr/include/openssl/opensslv.h
        0x0090800fL /usr/ports/openssl-0.9.8/crypto/opensslv.h
        0x0090800fL /usr/ports/openssl-0.9.8/include/openssl/opensslv.h
        0x0090800fL /Volumes/SystemFiles/local/include/openssl/opensslv.h

    Searching for OpenSSL shared library files.

    Searching for OpenSSL static library files.
    %

oddly, NO lib files -- shared OR static are found ....


nonetheless, the openssh build against openssl installed in /usr/local is all 
ok.

what am i missing so that findssl.sh is NOT FINDING the libs?

thx!

cheers,

richard



From dtucker at zip.com.au  Tue Jul 12 19:03:17 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 12 Jul 2005 19:03:17 +1000
Subject: openssh-4.1p1 on OSX 10.4.1 w/ openssl-0.9.8 NOT FINDING -lcrypto
In-Reply-To: <1F2EE9F0FD39A3E0575AA94E@tiedgar>
References: <E5CEB755ED4DE3D22B7E0943@tiedgar>
	<42D1C6E2.4000502@zip.com.au>	<E0ECC339C98F59F381F023FD@tiedgar>
	<42D1D554.5060804@zip.com.au> <D769A87D84A74513407B3DFF@tiedgar>
	<42D1DA17.9050806@zip.com.au> <1F2EE9F0FD39A3E0575AA94E@tiedgar>
Message-ID: <42D38755.2050705@zip.com.au>

OpenMacNews wrote:
> unfortunately, trying to build w/ static ssl/zlib on OSX opens up "a 
> whole nother can o worms" ... <sigh> ...

You don't have to build OpenSSH with -static, just make sure the there's 
no dynamic version of the relevant libraries in the link path.

> anyway, a question re: findssl.sh ...
[...]
> oddly, NO lib files -- shared OR static are found ....
> 
> nonetheless, the openssh build against openssl installed in /usr/local 
> is all ok.
> 
> what am i missing so that findssl.sh is NOT FINDING the libs?

Well, for one thing findssl doesn't know that *.dylib might be a 
library.  You can try the attached patch for that.

As far as the *.a libraries, I dunno.  The script uses an ugly hack to 
force the use of a particular library (ie it doesn't use -L) which works 
on most Unixes I know of, but maybe the OS X linker doesn't work that way.

-- 
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 --------------
An embedded and charset-unspecified text was scrubbed...
Name: findssl.patch
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20050712/c368bd45/attachment.ksh 

From timo.lilja at hut.fi  Tue Jul 12 07:47:29 2005
From: timo.lilja at hut.fi (Timo Lilja)
Date: Tue, 12 Jul 2005 00:47:29 +0300
Subject: Feature suggestion: sftp over ssh client in a single connection
Message-ID: <873bqlt3pq.fsf@frog.cs.hut.fi>

It has always bugged me that if I want to use a shell and perform some
file transfers in a single host I have to take two SSH connections:
one for the shell via ssh(1) and one for the file transfer via
sftp(1). Some graphical SSH clients can perform sftp operations and
ssh shell access in a single connection by using SSH2 protocol's
support for multiple channels.

So I hacked my openssh client to start the sftp prompt when the escape
sequence '~S' has been entered. The sftp session is implemented by
opening another channel into the same connection. After the user has
quit the sftp prompt, the client returns to the original ssh with
possible shell prompt or whatever.

The actual implementation is rather simple: The client basically forks
another process and runs a slightly modified version of the sftp
interactive_loop(). A little bit of hacking is needed so that the
primary ssh2_channel won't take the input/output while the sftp
session is active. The forking ensures that clientloop.c's select(2)
is performed normally so that the forwarded connections still work.

I can provide the patches if needed but since I am not very familiar
with the openssh code and not at all familiar with security related
code I think that someone who knows what he/she is doing might do a
better job ;-).

-- 
Timo Lilja

"It's a 106 miles to Chicago. We've got a full tank of gas, 
half a pack of cigarettes, it's dark, and we're wearing sunglasses."



From djm at mindrot.org  Tue Jul 12 21:19:20 2005
From: djm at mindrot.org (Damien Miller)
Date: Tue, 12 Jul 2005 21:19:20 +1000
Subject: Feature suggestion: sftp over ssh client in a single connection
In-Reply-To: <873bqlt3pq.fsf@frog.cs.hut.fi>
References: <873bqlt3pq.fsf@frog.cs.hut.fi>
Message-ID: <42D3A738.8010009@mindrot.org>

Timo Lilja wrote:
> It has always bugged me that if I want to use a shell and perform some
> file transfers in a single host I have to take two SSH connections:
> one for the shell via ssh(1) and one for the file transfer via
> sftp(1). 

Already done, using session multiplexing. See "ControlMaster" and
"ControlPath" in ssh_config(5).

-d



From dtucker at zip.com.au  Tue Jul 12 21:26:49 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 12 Jul 2005 21:26:49 +1000
Subject: Feature suggestion: sftp over ssh client in a single connection
In-Reply-To: <873bqlt3pq.fsf@frog.cs.hut.fi>
References: <873bqlt3pq.fsf@frog.cs.hut.fi>
Message-ID: <42D3A8F9.9070308@zip.com.au>

Timo Lilja wrote:
> It has always bugged me that if I want to use a shell and perform some
> file transfers in a single host I have to take two SSH connections:
> one for the shell via ssh(1) and one for the file transfer via
> sftp(1). Some graphical SSH clients can perform sftp operations and
> ssh shell access in a single connection by using SSH2 protocol's
> support for multiple channels.

You can sftp and a shell over a single SSH connection with the 
ControlMaster/ControlPath feature:

$ ssh -MS /tmp/sock sshserver
$ sftp -o 'ControlPath /tmp/sock' sshserver

(on the current development version you can do it more transparently 
with "ControlMaster auto").

> So I hacked my openssh client to start the sftp prompt when the escape
> sequence '~S' has been entered. The sftp session is implemented by
> opening another channel into the same connection. After the user has
> quit the sftp prompt, the client returns to the original ssh with
> possible shell prompt or whatever.

The above won't run sftp from an escape sequence, though.

-- 
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 timo.lilja at hut.fi  Tue Jul 12 22:08:10 2005
From: timo.lilja at hut.fi (Timo Lilja)
Date: Tue, 12 Jul 2005 15:08:10 +0300
Subject: Feature suggestion: sftp over ssh client in a single connection
In-Reply-To: <42D3A8F9.9070308@zip.com.au> (Darren Tucker's message of "Tue,
	12 Jul 2005 21:26:49 +1000")
References: <873bqlt3pq.fsf@frog.cs.hut.fi> <42D3A8F9.9070308@zip.com.au>
Message-ID: <8764vg5is5.fsf@frog.cs.hut.fi>

Darren Tucker <dtucker at zip.com.au> writes:

>You can sftp and a shell over a single SSH connection with the
>ControlMaster/ControlPath feature:
>
>$ ssh -MS /tmp/sock sshserver
>$ sftp -o 'ControlPath /tmp/sock' sshserver

Thanks. I wasn't aware of this feature at all. This is much more
generic and better approach than that what I had in mind and does
basically everything that I need.

One downside though: I need two terminal windows or screen(1) or
something similar to get this working. In other words, it is not easy
to switch back and forth between the terminal shell and sftp in a
single window. Maybe there could be an escape sequence in the ssh
client that drops the client into a local shell? (I guess you could do
this by escaping with '~^Z' and writing 'bg' in the shell, but this
will not detach the stdout of the ssh client from the terminal.)

-- 
Timo Lilja

"It's a 106 miles to Chicago. We've got a full tank of gas, 
half a pack of cigarettes, it's dark, and we're wearing sunglasses."



From OpenMacNews at speakeasy.net  Wed Jul 13 00:25:18 2005
From: OpenMacNews at speakeasy.net (OpenMacNews)
Date: Tue, 12 Jul 2005 07:25:18 -0700
Subject: openssh-4.1p1 on OSX 10.4.1 w/ openssl-0.9.8 NOT FINDING -lcrypto
In-Reply-To: <42D38755.2050705@zip.com.au>
References: <E5CEB755ED4DE3D22B7E0943@tiedgar>	<42D1C6E2.4000502@zip.com.au>
	<E0ECC339C98F59F381F023FD@tiedgar>	<42D1D554.5060804@zip.com.au>
	<D769A87D84A74513407B3DFF@tiedgar>	<42D1DA17.9050806@zip.com.au>
	<1F2EE9F0FD39A3E0575AA94E@tiedgar> <42D38755.2050705@zip.com.au>
Message-ID: <AEC620BC3B20A0F26886013C@tiedgar>

hi darren,

>> unfortunately, trying to build w/ static ssl/zlib on OSX opens up "a
>> whole nother can o worms" ... <sigh> ...
>
> You don't have to build OpenSSH with -static, just make sure the there's no
> dynamic version of the relevant libraries in the link path.

understood ... i'd already found your earlier posts (thx!) and had tried 
various combos of movig the static libs to a separate dir, 
--with-ldflags/cppflags, etc. ... just haven;t been able to get 'configure' to 
accept that LIBS ad HEADERS are same version.

it fids the CORRECT (i.e., *my*) version of the headers, but simply refuses to 
query the correct LIBS ... it keeps grabbing the OSX-native libs i /usr/lib

i suppose i could temporarily MOVE/RENAME the originals ... but that 'wrankles' 
a bit.

>> anyway, a question re: findssl.sh ...
> [...]
>> oddly, NO lib files -- shared OR static are found ....
>>
>> nonetheless, the openssh build against openssl installed in /usr/local
>> is all ok.
>>
>> what am i missing so that findssl.sh is NOT FINDING the libs?
>
> Well, for one thing findssl doesn't know that *.dylib might be a library.
> You can try the attached patch for that.

thx.  i'd already caught that and changed appropriately for ".so" --> ".dylib" 
support

> As far as the *.a libraries, I dunno.  The script uses an ugly hack to force
> the use of a particular library (ie it doesn't use -L) which works on most
> Unixes I know of, but maybe the OS X linker doesn't work that way.

<grumble>

thx,

cheers,

richard



From jmknoble at pobox.com  Wed Jul 13 02:32:15 2005
From: jmknoble at pobox.com (Jim Knoble)
Date: Tue, 12 Jul 2005 12:32:15 -0400
Subject: Feature suggestion: sftp over ssh client in a single connection
In-Reply-To: <8764vg5is5.fsf@frog.cs.hut.fi>
References: <873bqlt3pq.fsf@frog.cs.hut.fi> <42D3A8F9.9070308@zip.com.au>
	<8764vg5is5.fsf@frog.cs.hut.fi>
Message-ID: <20050712163215.GC24662@crawfish.ais.com>

Circa 2005-07-12 dixit Timo Lilja:

: One downside though: I need two terminal windows or screen(1) or
: something similar to get [ssh and sftp in one channel on one
: terminal] working.

An alternative to GNU screen is splitvt:

    http://freshmeat.net/projects/splitvt/
    http://www.devolution.com/~slouken/projects/splitvt/

-- 
jim knoble  |  jmknoble at pobox.com  |  http://www.pobox.com/~jmknoble/
(GnuPG fingerprint: 809F:09B9:9686:D035:4AB0::9455:124B:0A62:DD6A:76D6)
 .....................................................................
 :"The methods now being used to merchandise the political candidate :
 : as though he were a deodorant positively guarantee the electorate :
 : against ever hearing the truth about anything."   --Aldous Huxley :
 :...................................................................:



From openssh at roumenpetrov.info  Wed Jul 13 06:23:56 2005
From: openssh at roumenpetrov.info (Roumen Petrov)
Date: Tue, 12 Jul 2005 23:23:56 +0300
Subject: openssh-4.1p1 on OSX 10.4.1 w/ openssl-0.9.8 NOT FINDING -lcrypto
In-Reply-To: <42D38755.2050705@zip.com.au>
References: <E5CEB755ED4DE3D22B7E0943@tiedgar>	<42D1C6E2.4000502@zip.com.au>	<E0ECC339C98F59F381F023FD@tiedgar>	<42D1D554.5060804@zip.com.au>
	<D769A87D84A74513407B3DFF@tiedgar>	<42D1DA17.9050806@zip.com.au>
	<1F2EE9F0FD39A3E0575AA94E@tiedgar> <42D38755.2050705@zip.com.au>
Message-ID: <42D426DC.906@roumenpetrov.info>

Darren Tucker wrote:
[SNIP]
> 
> Well, for one thing findssl doesn't know that *.dylib might be a 
> library.  You can try the attached patch for that.
> 

I guess findssl should search for *.sl on HP-UX :-\



From hijinks at gmail.com  Wed Jul 13 11:37:09 2005
From: hijinks at gmail.com (Mike Zupan)
Date: Tue, 12 Jul 2005 21:37:09 -0400
Subject: sftp/scp mysql logging
Message-ID: <7227c6c7050712183743caf5c3@mail.gmail.com>

I am basing a patch off of the sftplogging project on sourceforge to
add support for mysql logging for both sftp/scp. I have mysql compiled
in successfully and logging fine on connects/quits but my issue is
sending a file.. it does the reading from the sockets in this function
i take it

static void
process_read(void)
{

Now it does that for each chunk that it gets over the socket from what
i can tell.. for the life of me i cannot find a place to put my mysql
log command when the file is completely done.. if anyone has any
pointers i'd love to hear from you

Thanks

Mike
-- 
http://www.zcentric.com/wiki
My Linux Howto/Tips Wiki



From dtucker at zip.com.au  Wed Jul 13 14:10:04 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 13 Jul 2005 14:10:04 +1000
Subject: openssh-4.1p1 on OSX 10.4.1 w/ openssl-0.9.8 NOT FINDING -lcrypto
In-Reply-To: <42D426DC.906@roumenpetrov.info>
References: <E5CEB755ED4DE3D22B7E0943@tiedgar>	<42D1C6E2.4000502@zip.com.au>	<E0ECC339C98F59F381F023FD@tiedgar>	<42D1D554.5060804@zip.com.au>	<D769A87D84A74513407B3DFF@tiedgar>	<42D1DA17.9050806@zip.com.au>	<1F2EE9F0FD39A3E0575AA94E@tiedgar>
	<42D38755.2050705@zip.com.au> <42D426DC.906@roumenpetrov.info>
Message-ID: <42D4941C.7020101@zip.com.au>

Roumen Petrov wrote:
> I guess findssl should search for *.sl on HP-UX :-\

Already have that covered, it looks for 'libcrypto.s\*'.

-- 
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 f_mohr at yahoo.de  Thu Jul 14 03:37:02 2005
From: f_mohr at yahoo.de (Frank Mohr)
Date: Wed, 13 Jul 2005 19:37:02 +0200
Subject: ssh-keygen problem with openssh-4* and openssl-0.9.7g on AIX
Message-ID: <42D5513E.4060005@yahoo.de>

hi

i got a strange error for openssh-4.0p1 and openssh-4.1p1
(didn't try other versions) with openssl-0.9.7g on AIX 5.1

openssl-0.9.7g and openssh build without errors,
"make test" for openssl returns no errors,
"make test" for openssh stops at the first connection test

"make test" for openssh with openssl-0.9.6m returns no errors
(i don't get errors for openssh with openssl-0.9.7g on Linux)

i found the following problem:

ssh-keygen creates a corrupt public key for rsa1
("keygen -t rsa1" and "keygen -yf testkey")
the public key starts with a sequence of 0 and
has only a few digits at the end
keygen -l returns key lengths between 80 and 128
for diffent keygen runs
the corrupt key isn't accepted in authorized_keys
(while the correct pub key from another system is)

rsa and dsa have no problems

frank

	

	
		
___________________________________________________________ 
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de



From appro at fy.chalmers.se  Thu Jul 14 05:09:38 2005
From: appro at fy.chalmers.se (Andy Polyakov)
Date: Wed, 13 Jul 2005 21:09:38 +0200
Subject: ssh-keygen problem with openssh-4* and openssl-0.9.7g on AIX
In-Reply-To: <42D5513E.4060005@yahoo.de>
References: <42D5513E.4060005@yahoo.de>
Message-ID: <42D566F2.5060109@fy.chalmers.se>

> i got a strange error for openssh-4.0p1 and openssh-4.1p1
> (didn't try other versions) with openssl-0.9.7g on AIX 5.1
> 
> openssl-0.9.7g and openssh build without errors,
> "make test" for openssl returns no errors,
> "make test" for openssh stops at the first connection test
> 
> "make test" for openssh with openssl-0.9.6m returns no errors
> (i don't get errors for openssh with openssl-0.9.7g on Linux)
> 
> i found the following problem:
> 
> ssh-keygen creates a corrupt public key for rsa1
> ("keygen -t rsa1" and "keygen -yf testkey")
> the public key starts with a sequence of 0 and
> has only a few digits at the end
> keygen -l returns key lengths between 80 and 128
> for diffent keygen runs
> the corrupt key isn't accepted in authorized_keys
> (while the correct pub key from another system is)

This is caused by a bug in PPC assembler code, which was fixed recently 
(see http://cvs.openssl.org/chngview?cn=14200). A.



From Andrew_Wong at national.com.au  Thu Jul 14 08:50:55 2005
From: Andrew_Wong at national.com.au (Andrew_Wong at national.com.au)
Date: Thu, 14 Jul 2005 08:50:55 +1000
Subject: no expiry message displayed when login.
Message-ID: <OF42B3CC70.2130EDE9-ONCA25703D.007CA0CB@national.com.au>





Hi,

I am not sure this is a bug in Openssh or not.
I am running Openssh 4.1p1. with openssl 0.9.7g

Scenario:
When my password is in the warning period, I logon via ssh and I did not
get the warning message which I should.
I enabled the DEBUG level to 3 and I can see that sshd did received the
warning message but It is not displayed  from login session.

Information from DEBUG :

Jul 13 17:05:31 tatiana sshd[25599]: [ID 579461 auth.debug]
pam_unix_account: entering pam_sm_acct_mgmt()
Jul 13 17:05:31 tatiana sshd[25599]: [ID 100510 auth.debug] ldap
pam_sm_acct_mgmt(n113839), flags = 0
Jul 13 17:05:31 tatiana sshd[25599]: [ID 800047 auth.debug] debug3: PAM:
sshpam_thread_conv entering, 1 messages
Jul 13 17:05:31 tatiana sshd[25599]: [ID 800047 auth.debug] debug3:
ssh_msg_send: type 4
Jul 13 17:05:31 tatiana sshd[25597]: [ID 800047 auth.debug] debug3:
ssh_msg_recv entering
Jul 13 17:05:31 tatiana sshd[25599]: [ID 800047 auth.debug] debug3: PAM:
do_pam_account pam_acct_mgmt = 0 (Success)
Jul 13 17:05:31 tatiana sshd[25599]: [ID 800047 auth.debug] debug3:
ssh_msg_send: type 0
Jul 13 17:05:31 tatiana sshd[25597]: [ID 800047 auth.debug] debug1: PAM:
Your password will expire in 3 days.
Jul 13 17:05:31 tatiana sshd[25597]: [ID 800047 auth.debug] debug3: PAM:
import_environments entering
Jul 13 17:05:31 tatiana sshd[25597]: [ID 800047 auth.debug] debug3:
sshpam_password_change_required 0
Jul 13 17:05:31 tatiana sshd[25597]: [ID 800047 auth.debug] debug3: PAM:
num env strings 0
Jul 13 17:05:31 tatiana sshd[25597]: [ID 800047 auth.debug] debug1: PAM:
num PAM env strings 0
Jul 13 17:05:31 tatiana sshd[25597]: [ID 800047 auth.debug] debug3:
mm_request_send entering: type 51
Jul 13 17:05:31 tatiana sshd[25597]: [ID 800047 auth.debug] debug3:
mm_request_receive entering
Jul 13 17:05:31 tatiana sshd[25597]: [ID 800047 auth.debug] debug3:
monitor_read: checking request 52
Jul 13 17:05:31 tatiana sshd[25597]: [ID 800047 auth.debug] debug3:
mm_answer_pam_respond
Jul 13 17:05:31 tatiana sshd[25597]: [ID 800047 auth.debug] debug2: PAM:
sshpam_respond entering, 0 responses
Jul 13 17:05:31 tatiana sshd[25597]: [ID 800047 auth.debug] debug3:
mm_request_send entering: type 53
Jul 13 17:05:31 tatiana sshd[25597]: [ID 800047 auth.debug] debug3:
mm_request_receive entering
Jul 13 17:05:31 tatiana sshd[25597]: [ID 800047 auth.debug] debug3:
monitor_read: checking request 54
Jul 13 17:05:31 tatiana sshd[25597]: [ID 800047 auth.debug] debug3:
mm_answer_pam_free_ctx
Jul 13 17:05:31 tatiana sshd[25597]: [ID 800047 auth.debug] debug3: PAM:
sshpam_free_ctx entering
Jul 13 17:05:31 tatiana sshd[25597]: [ID 800047 auth.debug] debug3: PAM:
sshpam_thread_cleanup entering
Jul 13 17:05:31 tatiana sshd[25597]: [ID 800047 auth.debug] debug3:
mm_request_send entering: type 55
Jul 13 17:05:31 tatiana sshd[25597]: [ID 800047 auth.debug] debug2:
monitor_read: 54 used once, disabling now
Jul 13 17:05:31 tatiana sshd[25597]: [ID 800047 auth.debug] debug3:
mm_request_receive_expect entering: type 46
Jul 13 17:05:31 tatiana sshd[25597]: [ID 800047 auth.debug] debug3:
mm_request_receive entering
Jul 13 17:05:31 tatiana sshd[25597]: [ID 800047 auth.debug] debug1:
do_pam_account: called
Jul 13 17:05:31 tatiana sshd[25597]: [ID 800047 auth.debug] debug3:
mm_request_send entering: type 47
Jul 13 17:05:31 tatiana sshd[25597]: [ID 800047 auth.info] Accepted
keyboard-interactive/pam for n113839 from 127.0.0.1 port 61295 ssh2

Please help.

Regards
Andrew
____________________________________________________
Andrew Wong
Enterprise System
Operation Platform Service
Southern Star Technology, National Australia Bank
1/122 Lewis Road,  Wantirna South 3152
Phone: (03) 9886 2844 Ext x32844
Email: andrew_wong at national.com.au
__________________________________________________

This email is sent by or on behalf of the named sender identified above. If
you do not wish to receive any email marketing material from this person in
the future, please forward the contents of this email to
unsubscriptions at national.com.au with the word "unsubscribe" in the subject
box. If you do not forward the contents of this email with your
unsubscription then it may not be able to be implemented.  If you wish to
unsubscribe from all central email marketing lists used by our business,
please forward the contents of this email to
unsubscriptions at national.com.au with the message "unsubscribe from all
central email marketing lists" in the subject box.  If you do not forward
the contents of this email with your unsubscription then it may not be able
to be implemented.


The information contained in this email communication may be confidential.
You should only disclose, re-transmit, copy, distribute, act in reliance on
or commercialise the information if you are authorised to do so.  Any views
expressed in this email communication are those of the individual sender,
except where the sender specifically states them to be the views of a
member of the National Australia Bank Group of companies.  Any advice
contained in this e-mail has been prepared without taking into account your
objectives, financial situation or needs. Before acting on any advice in
this e-mail, National Australia Bank Limited recommends that you consider
whether it is appropriate for your circumstances. If this e-mail contains
reference to any financial products, the National recommends you consider
the Product Disclosure Statement (PDS) or other disclosure document  before
making any decisions regarding any products.  The National Australia Bank
Group of companies does not represent, warrant or guarantee that the
integrity of this communication has been maintained nor that the
communication is free of errors, virus or interference.




From dissent at cvshome.org  Wed Jul 13 13:39:16 2005
From: dissent at cvshome.org (Alexander Taler)
Date: Tue, 12 Jul 2005 23:39:16 -0400
Subject: OpenSSH and non-blocking mode
In-Reply-To: <200507062126.j66LQWd04632@thor.net.plm.eds.com>
References: <200507062126.j66LQWd04632@thor.net.plm.eds.com>
Message-ID: <17108.36068.357742.560054@fire.0--0.org>


  Larry> 	$ cat bigfile | wc -c
  Larry> 	 10858893
  Larry> 	$ (ssh localhost sleep 120& sleep 3; cat bigfile) | wc -c
  Larry> 	cat: stdout: Resource temporarily unavailable
  Larry> 	  270336

  Damien> What platform are you using? This works fine on OpenBSD and Solaris.
  Damien> You could be running into a kernel bug.

For the record, I can reproduce this problem intermittently on
OpenBSD:

    fire $ uname -a
    OpenBSD fire.0--0.org 3.6 GENERIC#304 sparc64
    fire $ cat INBOX | wc -c
     4106962 
    fire $ (ssh localhost sleep 120& sleep 3; cat INBOX) | wc -c 
     4106962 
    fire $ (ssh localhost sleep 120& sleep 3; cat INBOX) | wc -c
    cat: stdout: Resource temporarily unavailable
      655360 

Alex

-- 
https://savannah.gnu.org/projects/libcvs-spec    Access CVS through a library.
PGP:  ID: 0x23DC453B  FPR: 42D0 66C2 9FF8 553A 373A  B819 4C34 93BA 23DC 453B
The pimp's trade must be carried out by intelligent people, is essential to any
well-ordered society, and should have an official inspector.  -- Don Quixote



From dtucker at zip.com.au  Thu Jul 14 14:44:09 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 14 Jul 2005 14:44:09 +1000
Subject: no expiry message displayed when login.
In-Reply-To: <OF42B3CC70.2130EDE9-ONCA25703D.007CA0CB@national.com.au>
References: <OF42B3CC70.2130EDE9-ONCA25703D.007CA0CB@national.com.au>
Message-ID: <42D5ED99.5070105@zip.com.au>

Sounds like this bug:
http://bugzilla.mindrot.org/show_bug.cgi?id=1053

There's a patch in there that ought to resolve it, if not please add a 
comment to the bug with details of your platform (you may also want to 
add yourself to the CC: list).

-- 
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 Jul 14 16:47:16 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 14 Jul 2005 16:47:16 +1000
Subject: openssh-4.1p1 on OSX 10.4.1 w/ openssl-0.9.8 NOT FINDING -lcrypto
In-Reply-To: <AEC620BC3B20A0F26886013C@tiedgar>
References: <E5CEB755ED4DE3D22B7E0943@tiedgar>	<42D1C6E2.4000502@zip.com.au>	<E0ECC339C98F59F381F023FD@tiedgar>	<42D1D554.5060804@zip.com.au>	<D769A87D84A74513407B3DFF@tiedgar>	<42D1DA17.9050806@zip.com.au>	<1F2EE9F0FD39A3E0575AA94E@tiedgar>
	<42D38755.2050705@zip.com.au> <AEC620BC3B20A0F26886013C@tiedgar>
Message-ID: <42D60A74.5010901@zip.com.au>

OpenMacNews wrote:
> it fids the CORRECT (i.e., *my*) version of the headers, but simply refuses to 
> query the correct LIBS ... it keeps grabbing the OSX-native libs i /usr/lib

It sounds like your linker is ignoring "-L" (or placing the additional 
paths on the end of the library search path).  Either way there's not a 
lot configure can do about 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.



From deengert at anl.gov  Fri Jul 15 00:24:27 2005
From: deengert at anl.gov (Douglas E. Engert)
Date: Thu, 14 Jul 2005 09:24:27 -0500
Subject: openssh and kerb 1.4.1 not so happy together
In-Reply-To: <20050707214309.GO8907@usc.edu>
References: <20050707010514.GG27759@usc.edu>	<Pine.LNX.4.44.0507071017330.31647-100000@hadrian.inf.ed.ac.uk>	<20050707200205.GH8907@usc.edu>
	<20050707214309.GO8907@usc.edu>
Message-ID: <42D6759B.7020602@anl.gov>



Phil Dibowitz wrote:

> On Thu, Jul 07, 2005 at 01:02:05PM -0700, Phil Dibowitz wrote:
> 
>>On Thu, Jul 07, 2005 at 10:20:29AM +0100, sxw at inf.ed.ac.uk wrote:
>>
>>>On Wed, 6 Jul 2005, Phil Dibowitz wrote:
>>>
>>>
>>>>Turns out that makes the error clear:
>>>>
>>>>ld.so.1: /usr/lsd/openssh/default/sbin/sshd: fatal: relocation error: file
>>>>/usr/lsd/openssh/default/sbin/sshd: symbol krb5_init_ets: referenced symbol
>>>>not found
>>>>Killed
>>>>
>>>>Of course, that's not the recompiled version.... but the recompiled version
>>>>has the same external symptoms. Hmmm.
>>>
>>>You need to do a make distclean, and then re-run ./configure. I would 
>>>imagine that the soname didn't change because krb5_init_ets isn't part of 
>>>MIT's officially exported API.
>>>
>>>We should probably just pull the call to krb5_init_ets - its been years 
>>>since any version of Kerberos required it.
>>
>>Tried that, same symptom, different problem. the sshd -ddd gives:
>>
>>Assertion failed: i->did_run != 0, file
>>../../../../src/lib/krb5/../../include/k5-pla
>>tform.h, line 232
> 
> 
> OK, well this isn't entirely accurate.
> 
> The full recompile with make distclean fixes Solaris 8 and Solaris 9 machines.
> I only get the above on Solaris 2.6.

Since Solaris 2.6 is old, you may want to compile krb5-1.4.1. On Solaris 7
we compile with --disable-thread-support and CPPFLAGS = -D_TS_ERRNO

We also compiled OpenSSH-4.1 with -DUNSUPPORTED_POSIX_THREADS_HACK

krb5-1.4.1 with OpenSSH-4.1 works on Solaris, 7, 8, 9 and 10.
(10 is still under testing, and we are trying to use the Sun version.)


> 
> Further, I get it in other apps as well.
> 
> Which leads me to believe it's a kerb issue. I'll drop them an email. Thanks.
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444



From joerg at britannica.bec.de  Fri Jul 15 04:53:27 2005
From: joerg at britannica.bec.de (Joerg Sonnenberger)
Date: Thu, 14 Jul 2005 20:53:27 +0200
Subject: OpenSSH PAM "thread" buglet
Message-ID: <20050714185327.GA16347@britannica.bec.de>

Hi all,
the attached patch ensure that only one side of the authentication
socketpair stays open on both sides. This should make the code
more robust by detecting the dead of the process on the other side.
This applies to the non-pthread case only.

Joerg 
-------------- next part --------------
Index: auth-pam.c
===================================================================
RCS file: /home/joerg/wd/repository/dragonflybsd/src/crypto/openssh-4/auth-pam.c,v
retrieving revision 1.1
diff -u -r1.1 auth-pam.c
--- auth-pam.c	14 Jul 2005 13:10:21 -0000	1.1
+++ auth-pam.c	14 Jul 2005 13:25:58 -0000
@@ -150,6 +150,7 @@
     void *(*thread_start)(void *), void *arg)
 {
 	pid_t pid;
+	struct pam_ctxt *ctx = arg;
 
 	sshpam_thread_status = -1;
 	switch ((pid = fork())) {
@@ -157,10 +158,14 @@
 		error("fork(): %s", strerror(errno));
 		return (-1);
 	case 0:
+		close(ctx->pam_psock);
+		ctx->pam_psock = -1;
 		thread_start(arg);
 		_exit(1);
 	default:
 		*thread = pid;
+		close(ctx->pam_csock);
+		ctx->pam_csock = -1;
 		sshpam_oldsig = signal(SIGCHLD, sshpam_sigchld_handler);
 		return (0);
 	}

From jg at jguk.org  Fri Jul 15 08:37:57 2005
From: jg at jguk.org (J. Grant)
Date: Thu, 14 Jul 2005 23:37:57 +0100
Subject: sftp backspace not working (OpenSSH_3.8.1p1 Debian-8.sarge.4)
In-Reply-To: <42D1B588.3020702@mindrot.org>
References: <42D143E4.9010305@jguk.org> <42D1B588.3020702@mindrot.org>
Message-ID: <42D6E945.5020706@jguk.org>



On 11/07/05 00:55, Damien Miller wrote:
> J. Grant wrote:
> 
>> I am using sftp which comes with OpenSSH_3.8.1p1 Debian-8.sarge.4,
>> OpenSSL 0.9.7e 25 Oct 2004
>>
>> I noticed backspace is not working. Couild someone tell me if this is
>> fixed in a newer package please?
> 
> 
> Why don't you ask the Debian maintainer - this is a very
> distribution-specific problem.

By that do you intend to make the point that there was no bug? Or there
was a bug and it has been fixed for sometime? Or there was a only bug in
debian build?  Or something else entirely?

Please include my email address in replies.

Kind regards
JG



From djm at mindrot.org  Fri Jul 15 09:57:18 2005
From: djm at mindrot.org (Damien Miller)
Date: Fri, 15 Jul 2005 09:57:18 +1000
Subject: sftp backspace not working (OpenSSH_3.8.1p1 Debian-8.sarge.4)
In-Reply-To: <42D6E945.5020706@jguk.org>
References: <42D143E4.9010305@jguk.org> <42D1B588.3020702@mindrot.org>
	<42D6E945.5020706@jguk.org>
Message-ID: <42D6FBDE.50203@mindrot.org>

J. Grant wrote:
> 
> 
> On 11/07/05 00:55, Damien Miller wrote:
> 
>> J. Grant wrote:
>>
>>> I am using sftp which comes with OpenSSH_3.8.1p1 Debian-8.sarge.4,
>>> OpenSSL 0.9.7e 25 Oct 2004
>>>
>>> I noticed backspace is not working. Couild someone tell me if this is
>>> fixed in a newer package please?
>>
>>
>>
>> Why don't you ask the Debian maintainer - this is a very
>> distribution-specific problem.
> 
> 
> By that do you intend to make the point that there was no bug? Or there
> was a bug and it has been fixed for sometime? Or there was a only bug in
> debian build?  Or something else entirely?

I mean that the bug is probably not in OpenSSH itself - it it likely to
be in Debian's libedit or termcap.

-d



From dtucker at zip.com.au  Fri Jul 15 13:18:30 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 15 Jul 2005 13:18:30 +1000
Subject: OpenSSH PAM "thread" buglet
In-Reply-To: <20050714185327.GA16347@britannica.bec.de>
References: <20050714185327.GA16347@britannica.bec.de>
Message-ID: <42D72B06.4090401@zip.com.au>

Joerg Sonnenberger wrote:
> Hi all,
> the attached patch ensure that only one side of the authentication
> socketpair stays open on both sides. This should make the code
> more robust by detecting the dead of the process on the other side.
> This applies to the non-pthread case only.

Can you give an example where it would make a difference?  The death of 
the child process should already be caught by the SIGCHLD.  Or are you 
talking about the parent dying unexpectedly and the child not getting a 
SIGPIPE?

-- 
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 joerg at britannica.bec.de  Fri Jul 15 23:57:20 2005
From: joerg at britannica.bec.de (Joerg Sonnenberger)
Date: Fri, 15 Jul 2005 15:57:20 +0200
Subject: OpenSSH PAM "thread" buglet
In-Reply-To: <42D72B06.4090401@zip.com.au>
References: <20050714185327.GA16347@britannica.bec.de>
	<42D72B06.4090401@zip.com.au>
Message-ID: <20050715135720.GA1033@britannica.bec.de>

On Fri, Jul 15, 2005 at 01:18:30PM +1000, Darren Tucker wrote:
> Joerg Sonnenberger wrote:
> >Hi all,
> >the attached patch ensure that only one side of the authentication
> >socketpair stays open on both sides. This should make the code
> >more robust by detecting the dead of the process on the other side.
> >This applies to the non-pthread case only.
> 
> Can you give an example where it would make a difference?  The death of 
> the child process should already be caught by the SIGCHLD.  Or are you 
> talking about the parent dying unexpectedly and the child not getting a 
> SIGPIPE?

The current code depends on the SIGCHLD in the parent, if that gets lost,
it will never detect it. Given that the current code already plays with
more than one child, it's an assumption, which needs to be justified.
Closing one side allows it to detect the death of the child nevertheless.

The same situation applies to the child too, yes. The comment in the FreeBSD
code explicitly refers to the SIGALRM handling, it seems that the child could
remain orphaned in case of timeouts.

Joerg



From dtucker at zip.com.au  Sat Jul 16 11:37:07 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Sat, 16 Jul 2005 11:37:07 +1000
Subject: OpenSSH PAM "thread" buglet
In-Reply-To: <20050715135720.GA1033@britannica.bec.de>
References: <20050714185327.GA16347@britannica.bec.de>
	<42D72B06.4090401@zip.com.au>
	<20050715135720.GA1033@britannica.bec.de>
Message-ID: <42D864C3.2040109@zip.com.au>

Joerg Sonnenberger wrote:
[...]
> The current code depends on the SIGCHLD in the parent, if that gets lost,
> it will never detect it. Given that the current code already plays with
> more than one child, it's an assumption, which needs to be justified.
> Closing one side allows it to detect the death of the child nevertheless.

OK fair enough.  I was able to replicate the case where the monitor dies 
unexpectedly (by kill -9'ing it on Linux) and confirmed that it helps 
there too.  Applied, 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 senthilkumar_sen at hotpop.com  Sat Jul 16 20:28:58 2005
From: senthilkumar_sen at hotpop.com (Senthil Kumar)
Date: Sat, 16 Jul 2005 15:58:58 +0530
Subject: Pam module leaks information
Message-ID: <0b9101c589f1$2fb08b70$220110ac@sekco>

Hello All,

Im using OpenSSH 4.1 with a proprietary pam module. This module does allow
or deny access to the accound based on a policy file settings. Now if I deny
the access to an account and attempt to connect to the sshd server for that
account with valid password, it quickly returns to next prompt. When I try
it with invalid password, it took some time to return to next prompt. Im
wondering if this kind of behaviour will lead to information leak on
password validity. Should I need to contact the author of this module to
compensate the difference in timing factor.

Thanks,
Senthil Kumar.




From jg at jguk.org  Sun Jul 17 03:31:45 2005
From: jg at jguk.org (J. Grant)
Date: Sat, 16 Jul 2005 18:31:45 +0100
Subject: mindrot.org TMDA sending multiple auto-responder spams
Message-ID: <42D94481.8050902@jguk.org>

Hi,

It is a shame I feel obliged to write this email.

I sent a single email with a possible bug in it, asking if it was
working in a newer release.  I got 3 spam emails from mindrot.org.  Two
asking me to confirm, and then when I was forced to confirm I got
another auto-responder spam.  If I had wanted the 3rd spam I would have set
"return receipt".

I got this (below) auto-responder confirmation spam as well.  I confirmed
my email address purely so I could make the point that this approach is
a poor solution to spam prevention.  This approach treats symptom of
spam by wasting the time of email person with yet more spam, rather than
tackling the cause of the problem.

Is there a logical reason for this odd approach?

I posted about these sort of flawed approaches earlier this year:

"Auto-responder anti-spam solutions"
http://jguk.org/2005/blog_2005_06_01_auto_responder_anti_spam.html

I do not wish my email address to be listed on mindrot.org now I have
made this point, please remove it from the list of people who are excluded
from being spammed by default.  I will not reply to further emails unless
there is a clear indication that this fault has been corrected and when I
reply I will not be spammed again.

Kind regards
JG

-------- Original Message --------
Subject: Please confirm your message
Date: Mon, 11 Jul 2005 01:46:01 +1000 (EST)
From: TMDA daemon <tmda at mindrot.org>
Reply-To: tmda+confirm+1121010361.31290.971921 at mindrot.org
To: jg at jguk.org
References: <42D143E4.9010305 at jguk.org>

This message was created automatically by mail delivery software (TMDA).

Your message attached below is being held because the address
<jg at jguk.org> has not been verified.

To release your message for delivery, please send an empty message
to the following address, or use your mailer's "Reply" feature.

      tmdaaaaaaaaaaaaaaaaaaaa90.971921 at mindrot.org

This confirmation verifies that your message is legitimate and not
junk-mail. You should only have to confirm your address once.

If you do not respond to this confirmation request within 14 days,
your message will not be delivered.



From djm at mindrot.org  Sun Jul 17 10:50:53 2005
From: djm at mindrot.org (Damien Miller)
Date: Sun, 17 Jul 2005 10:50:53 +1000
Subject: mindrot.org TMDA sending multiple auto-responder spams
In-Reply-To: <42D94481.8050902@jguk.org>
References: <42D94481.8050902@jguk.org>
Message-ID: <42D9AB6D.2010607@mindrot.org>

The challenge-response is a one-time confirmation that is required of
people who do not subscribe to the mailing list.

It is intended to provide a simple way for people who want to report
bugs, etc. without becoming involved in general list discussions. The
alternative would be to force everyone who wants to send in reports to
subscribe first and then unsubscribe later, which is far more of an
impost than replying to a one-off challenge email.

You only need to authorise yourself once and they go away - you are not
rechallenged after you have been authorised (you received two challenges
because you sent two messages without responding.)

Please direct further discussion on this topic to me rather than the
list.

-d

J. Grant wrote:
> Hi,
> 
> It is a shame I feel obliged to write this email.
> 
> I sent a single email with a possible bug in it, asking if it was
> working in a newer release.  I got 3 spam emails from mindrot.org.  Two
> asking me to confirm, and then when I was forced to confirm I got
> another auto-responder spam.  If I had wanted the 3rd spam I would have set
> "return receipt".
> 
> I got this (below) auto-responder confirmation spam as well.  I confirmed
> my email address purely so I could make the point that this approach is
> a poor solution to spam prevention.  This approach treats symptom of
> spam by wasting the time of email person with yet more spam, rather than
> tackling the cause of the problem.
> 
> Is there a logical reason for this odd approach?
> 
> I posted about these sort of flawed approaches earlier this year:
> 
> "Auto-responder anti-spam solutions"
> http://jguk.org/2005/blog_2005_06_01_auto_responder_anti_spam.html
> 
> I do not wish my email address to be listed on mindrot.org now I have
> made this point, please remove it from the list of people who are excluded
> from being spammed by default.  I will not reply to further emails unless
> there is a clear indication that this fault has been corrected and when I
> reply I will not be spammed again.
> 
> Kind regards
> JG
> 
> -------- Original Message --------
> Subject: Please confirm your message
> Date: Mon, 11 Jul 2005 01:46:01 +1000 (EST)
> From: TMDA daemon <tmda at mindrot.org>
> Reply-To: tmda+confirm+1121010361.31290.971921 at mindrot.org
> To: jg at jguk.org
> References: <42D143E4.9010305 at jguk.org>
> 
> This message was created automatically by mail delivery software (TMDA).
> 
> Your message attached below is being held because the address
> <jg at jguk.org> has not been verified.
> 
> To release your message for delivery, please send an empty message
> to the following address, or use your mailer's "Reply" feature.
> 
>       tmdaaaaaaaaaaaaaaaaaaaa90.971921 at mindrot.org
> 
> This confirmation verifies that your message is legitimate and not
> junk-mail. You should only have to confirm your address once.
> 
> If you do not respond to this confirmation request within 14 days,
> your message will not be delivered.
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev



From dtucker at zip.com.au  Mon Jul 18 14:14:24 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Mon, 18 Jul 2005 14:14:24 +1000
Subject: Pam module leaks information
In-Reply-To: <0b9101c589f1$2fb08b70$220110ac@sekco>
References: <0b9101c589f1$2fb08b70$220110ac@sekco>
Message-ID: <42DB2CA0.8040608@zip.com.au>

Senthil Kumar wrote:
> Im using OpenSSH 4.1 with a proprietary pam module. This module does allow
> or deny access to the accound based on a policy file settings. Now if I deny
> the access to an account and attempt to connect to the sshd server for that
> account with valid password, it quickly returns to next prompt. When I try
> it with invalid password, it took some time to return to next prompt. Im
> wondering if this kind of behaviour will lead to information leak on
> password validity. Should I need to contact the author of this module to
> compensate the difference in timing factor.

I'm not aware of any remaining timing info leaks in the PAM code in 
OpenSSH 4.1p1 (we spent some time a while back stomping them out) but if 
there are any left then they ought to be found and fixed.

That said, it sounds like your module is the source of the timing 
discrepancy.  Does it behave the same way with other PAM apps?

What platform is this?  On Linux, you may have to explicitly set 
pam_fail_delay (eg with this module: 
http://www.zip.com.au/~dtucker/patches/#pam_faildelay).

-- 
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 senthilkumar_sen at hotpop.com  Mon Jul 18 20:32:54 2005
From: senthilkumar_sen at hotpop.com (Senthil Kumar)
Date: Mon, 18 Jul 2005 16:02:54 +0530
Subject: Pam module leaks information
References: <0b9101c589f1$2fb08b70$220110ac@sekco>
	<42DB2CA0.8040608@zip.com.au>
Message-ID: <0e6601c58b84$10abb6c0$220110ac@sekco>

Darren wrote:


> Senthil Kumar wrote:
>> Im using OpenSSH 4.1 with a proprietary pam module. This module does 
>> allow
>> or deny access to the accound based on a policy file settings. Now if I 
>> deny
>> the access to an account and attempt to connect to the sshd server for 
>> that
>> account with valid password, it quickly returns to next prompt. When I 
>> try
>> it with invalid password, it took some time to return to next prompt. Im
>> wondering if this kind of behaviour will lead to information leak on
>> password validity. Should I need to contact the author of this module to
>> compensate the difference in timing factor.
>
> I'm not aware of any remaining timing info leaks in the PAM code in
> OpenSSH 4.1p1 (we spent some time a while back stomping them out) but if
> there are any left then they ought to be found and fixed.
>
> That said, it sounds like your module is the source of the timing
> discrepancy.  Does it behave the same way with other PAM apps?

When I test this module with telnet with valid password entered they close 
the conn. With invalid passwd they prompt for password after some delay. The 
same behaviour happens for password auth. with sshd. With challengeresponse, 
for valid password it return quickly to next prompt and with invalid 
password it took some time.

>
> What platform is this?  On Linux, you may have to explicitly set
> pam_fail_delay (eg with this module:
> http://www.zip.com.au/~dtucker/patches/#pam_faildelay).
>

This happens in hpux.

Thanks,
Senthil Kumar. 




From dtucker at zip.com.au  Tue Jul 19 00:21:35 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 19 Jul 2005 00:21:35 +1000
Subject: Pam module leaks information
In-Reply-To: <0e6601c58b84$10abb6c0$220110ac@sekco>
References: <0b9101c589f1$2fb08b70$220110ac@sekco>
	<42DB2CA0.8040608@zip.com.au>
	<0e6601c58b84$10abb6c0$220110ac@sekco>
Message-ID: <42DBBAEF.3030009@zip.com.au>

Senthil Kumar wrote:
> Darren wrote:
>> That said, it sounds like your module is the source of the timing
>> discrepancy.  Does it behave the same way with other PAM apps?
> 
> When I test this module with telnet with valid password entered they 
> close the conn.

That's a bit suspicious, are they checking the PAM service name or 
something?  Or is it password -> delay -> close connection?

> With invalid passwd they prompt for password after some 
> delay. The same behaviour happens for password auth. with sshd. With 
> challengeresponse, for valid password it return quickly to next prompt 
> and with invalid password it took some time.

It's possible that your module is stashing something using pam_set_data 
and then inserting the delay and failing out during the account phase. 
It's pretty hard to tell without looking at the module's code.

I added a timestamp option (-v) to my PAM test harness, this may help 
show where the delays are ocurring:
http://www.zip.com.au/~dtucker/patches/#pamtest

-- 
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 hbhaskaran at gmail.com  Tue Jul 19 09:46:22 2005
From: hbhaskaran at gmail.com (Hari Bhaskaran)
Date: Mon, 18 Jul 2005 16:46:22 -0700
Subject: problem moving hostkey from ssh version 3.5p1 to 3.8p
Message-ID: <8d03025a05071816467f86b22e@mail.gmail.com>

Hi,

I am trying to upgrade from OpenSSH_3.5p1 FreeBSD 4.8 to 
OpenSSH_3.8p1 (Suse 9.1). Although the host rsa and dsa
keys have been copied over from old to new machine, linux ssh
clients (3.8p1) still bring up the new-key alert. ssh clients
from freebsd machines till OpenSSH_3.6.1p1 work fine with 
the setup (without the new key alert)

ssh -vv shows linux clients are looking for type 0 and type 2 key and
freebsd ones are looking for type 0 and type 1 keys

Is this some known incompatibility between ssh 3.6 vs 3.8 or something
between linux vs freebsd?

Any help is appreciated
Thank you.



From dtucker at zip.com.au  Tue Jul 19 10:16:29 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 19 Jul 2005 10:16:29 +1000
Subject: problem moving hostkey from ssh version 3.5p1 to 3.8p
In-Reply-To: <8d03025a05071816467f86b22e@mail.gmail.com>
References: <8d03025a05071816467f86b22e@mail.gmail.com>
Message-ID: <42DC465D.6050309@zip.com.au>

Hari Bhaskaran wrote:
> Hi,
> 
> I am trying to upgrade from OpenSSH_3.5p1 FreeBSD 4.8 to 
> OpenSSH_3.8p1 (Suse 9.1). Although the host rsa and dsa
> keys have been copied over from old to new machine, linux ssh
> clients (3.8p1) still bring up the new-key alert. ssh clients
> from freebsd machines till OpenSSH_3.6.1p1 work fine with 
> the setup (without the new key alert)
> 
> ssh -vv shows linux clients are looking for type 0 and type 2 key and
> freebsd ones are looking for type 0 and type 1 keys

Type 0 keys are protocol 1 RSA, type 1 are protocol 2 RSA and type 3 are 
protocol 2 DSA.

> Is this some known incompatibility between ssh 3.6 vs 3.8 or something
> between linux vs freebsd?

Probably not.  The host key type is selected on the client side (see 
"HostKeyAlgorithms" in ssh_config), just change your clients to suit.  I 
don't think the default has changed for a long time (in the main code, 
anyway, FreeBSD may have done something differently).

If changing the clients is a big hassle you could disable the DSA key in 
sshd_config (specify 2 HostKey entries, one for RSA1 and one for RSA2).

-- 
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 bob at proulx.com  Tue Jul 19 17:51:41 2005
From: bob at proulx.com (Bob Proulx)
Date: Tue, 19 Jul 2005 01:51:41 -0600
Subject: sftp backspace not working (OpenSSH_3.8.1p1 Debian-8.sarge.4)
In-Reply-To: <42D143E4.9010305@jguk.org>
References: <42D143E4.9010305@jguk.org>
Message-ID: <20050719075141.GA3326@dementia.proulx.com>

J. Grant wrote:
> I am using sftp which comes with OpenSSH_3.8.1p1 Debian-8.sarge.4,
> OpenSSL 0.9.7e 25 Oct 2004

Me too.  It works fine for me.  And I find it hard to believe this is
a package bug.  This smells more like a configuration error.

> I noticed backspace is not working. Couild someone tell me if this is
> fixed in a newer package please?

The most likely source of problems is a misconfigured tty driver erase
character setting.  You should first verify your setting.

  stty -a

Look for the erase setting.  You should see:

  erase = ^?

But possibly you might see:

  erase = ^H

Regardless, it must match what is being produced by the key on your
keyboard.  If you are using a Linux kernel then the key will produce
the ^? DEL character and should be set to that.  If it does not then
the key will not be recognized as an erase character and you will see
either ^? or ^H depending upon which it happens to be.

  stty erase ^?

That is the default on Debian systems.  But other systems, most
notably commercial SysV systems, often use ^H for that character.  If
you have a ~/.profile or other environment file from one of those
systems you may be setting the erase character incorrectly.

If you believe this to be a Debian package bug then you should use the
'reportbug' script from the reportbug package to file a bug in the BTS
about your problem.

Bob



From geekheaven at arcor.de  Wed Jul 20 00:34:36 2005
From: geekheaven at arcor.de (Sebastian Wieseler)
Date: Tue, 19 Jul 2005 16:34:36 +0200
Subject: key_read: uudecode 
Message-ID: <42DD0F7C.2040705@arcor.de>

Hello guys, mabye this can help you somehow:

$ ssh-keygen -b 8192 -g -t dsa
...
...

$ cat .ssh/id_dsa.pub
ssh-dss 
AAAAB3NzaC1kc3MAAAQBANWV7bN8pqNeMAzcANYR1FyvKYuOCNIwU/xI4htk3fAp+LG1aApwVHXyrqkMf2OwngSyzmaSJCya6fsUjla+0yPsT/KjS2/U0lHmyjzqX2AyKl3+0fPl4OH9ilMugXO3G5lqMeeb4A/ALRBRzw0w9WB10zBZxJvdLRUwdkvRTKynGAEUC08+Qo04enWINTp2dV6VW9Ghf+Miete4mb7dPJrnPk9MVAxJ5Sn5079Tx4j5MfAjAvBQWI4nJ/O59rz0w5ZuEo1Z7y7EV8JhNJj5ZfRszOyNau+IdD+/z5o8tDO2Zwkr5twfRJPo5sh6cRlJx2MHhO9W/2RAPXgEayzRCy5aTscgEAQru/KP6AyJ0hxmRKlP5+nNBI5qXRz+6oapJo+rV97TF25qrtTREN6HlPKuGqsvz6cf9g7gbRaAD2AB3p/Znmg9l3njHxTqG/A74L/KObVnfxZOA52FfATF/oQ7foxpUiBh27T3S+xmfbzeX+JpStpteQ+YnVL0fSb+osGwGSkxOy7PadQevhhvChWmCbgsRuaUoY3vY3bfTZ3yK3HO4kORIkODJ5YGReQxYDWinxII1dDAFvNazkicRGVJst2i33rmUkIs6nKC5RJH7SIQ+ks4t4adMUbd3LaC78RH0tsVkPDY20gNzwT2tcN4+ranFpYS1wyzcEbfbOAYsT/YNovFdBcVM3u3tGf5EoyCluao1R8Vg4r+e6WbcszHqIRLn3ATGNX55XLCem9QYTr0GBZwPKQnrDXlbEiNHKOArKIwV/6OPu1y5kowM9TOHy8D+kE+VbUvUCHfjNOm8Lc7ZgByYHKsrOe/piBGAGWzFSy/WTIyhlEapq6qlMpMhLuOXsdhaWnNUDsghArJWfHPigekbtfOBZGWq//V5FYLs8l17DIKzPVKqlZVoXK73/3RN+uUyomfLmP/Ww+4UObkQImC5LwtiziCIrDp5R+cjBF+Jb
tzEZ0k36N3dRUAtAVzd4JuA5M1HqT8MtwZrMgq7zp6tmvQ5GWDYrt/ZZ8QBfI+cNcxDeKj2D44l5LnEwcHH028w4otRdO3azUsGoZkS2rPWvQx6UnnE5VJHE6qL49mOSEWxMV9g62wkbMVvTdIHQdv38MogBaRiVCfEtfW02nuyv5GqyuE9jcoOVn8zyX1Cf2ywTMBT5Fmg3hcAtkzLb60mFE94b2/rnl6+1YexyitnkWy3c5spwkxBCT3gK3L82thivOU3rn8VfEw7NutxRrX5ffBnCarhTK12pcwjz4ZRDmjeIiKtBnYnghmRIrd+zgYlmGpV3gOtgSxSvdbcwCGAlkE/KDcRKvKOJrJJbWxQkuSXxZ1GFojV+ZK+I+EQTzN/R9yo7XfH5MAAAAVAMM0g6vWlUaT9STCENxqaG7jqJpTAAAEAGXjWFooDVlY3HCK+1vyMGTPDdK8BgbRuhmKZlQVeyOO9s8BpP2SnbePyWBA5QhL93NWnxqFQLa1r2nogFalaRpzI2bFpJHH6fk+JqYUNLQdysOw7hvPtHgp0ToxP8200Q/HAfcRtD6HDV4JjmiYfyhMYjpB7nAYp3CguKEkLbbMoU+1uASzSW1VLCYMBVC9LYpgsjURQwq/7IfyUGSLtxzN4I3jOJEEOtIs02Pb2j9eJY9Jc6pN5bZSpOlr+i1yvLnXCoPwHZDiz0SPucB1IXrepJBA41eFiZ0pas+3ksniju6y7DUJWE0gngoLKCweAYGKr2U3vx7QWpmqOdTM0o6vdpV4rQ8/U7/33Yzkflb5ItlfYutCkzhMAb4DAUbs55/k8xPebOMlQsHN3c9w9mCyVr0ULTVFm6pOgFoKmBqcitRMc8pZQE0Pdlke0gxLheG92mb5/CIdi+qGIwW06T4tJnHVVL59J/RCDAZ7p8Ytbagweb00Vywo1O0Ipg1zt2jbmuh+ovoQt+lmglbcVL3+j0W+u7GdE0Dw9xajYSeO
+UcArfiKV6yc48YncEflPDSr0rV0jQ1Pd0tSBl+zMLwayGVlPmL626DFkDtyTLnYTaGuOKeB9T3OlqAK4Yo/8Tip9sg/EmZ2heD8w+tJQwl+88WZpHONUbbZ4J/83yZKDWkl0f3TRMb/q0W8Z0PoGa6jKo0ZslIxj/kBAgASe3u3BrPILSgJdNfdOn7fOxUra2RCbhjK58+aVgDJemaHLlxDTWxzB9YKMqNJxmtqtSs1nEuhIwySCpTL6diXc1TmQCsTxhM+6y/dKAPA1LN1jIulAQZoiGz5FiDIX+BTOPmUEUkkWgYi27RcrHbUgrKVaHc0iJusEsn91he/VoQyKAus+6QzALXW/BBMd1LsRdVXcL1KU4ywjvxerbMnnbRNqN+Oy53p5ISRl+AQ7azq7N7GkBDYXf95T1YCxSVSfT+H21PHp3VUtwfSrH3JDCFXlHiQTY2Y/5TGX8JHGdbj5FmWycu8j3E8pacVC0YkKNNlovkpq6h8Y6uiztrWfQnq/LdEYHLRRk1q+6sYrDi4wySwNMHDUMjQgUgWlE7gjkMGj7DdmmOQRsT0dKZrXCQyZxVO6vjtakWRZ4sAI+YUdVsUfKK4apCC2E/an+250KGqoJXmnwxY1LF/Tjf8Gc+R/ejx3Elq5q5sJJP28jw08TTDzflHIHODUPIwzriRE4lf5lxSKb3+l8GmAAcTHmOObXBiVcseKoF7ib4tbe9IpCHL4EfXl8+mHeiKlm97kq6I/42Nm2zyZ4kMd5KuYtS9mlJbfKKrgznFQaPKjT4dEbcM5Bpg55bKjKV/dedAin8AAAQBALkXyENaTkFEex0yYn/5ZSJW/DuWO1tQBFjByKB3f+Yi/8AXMrd3+nazrndSvXi5i0eTy/26ArmV64DLnjl4o/AUS/IKpBlrYYRpXp6M+dvLNljubPK6fZLXro2QCq/xpNaoFcbNbpkjVYEfJv6M7L0rxuRuQydtM9+sSpSm9qsqxt
eD+JU3t0h12w2Pt6N3NjMqO89L5SrlrPny/wZ4y2Uh+rI1BBDyZaqZlZ2Rjfa+hVjO983ACyCrmdemQXIVtPBf7fMGnl1+PckFigl9NIblEf9EMYVvGBejS0VntrtDb8IST6kSd4Ju2jkC+wOYfupcErbGiCkU0AEFn6hAfIi6CjPLN03b/Kiy4Xdt4C+mtYZLXL3BG7FV/9ZKDDdN/hLwvBbJuj6VqOiHdCv1axYhEUqc7X1AKsKVMvOsySfFPyA9Nv7kY1HpvOFA+KcZTz+yQBeIAQSfBGdlbB5Rl4VZZ7zAdqJNexNeznEql3yMLcAy4HRVtazQm27FKgtTyD9E9T8PnztiHZPEYEOFf9ySDegIiEL/AH4L2ZWM+mjB4Z4X6qnNORyvSYBusKkNJKPeBPrOw7UpK/g5zisG5YHOmI7OqgEWUc32uuGHCfUNRRLNkwN8260xkOLixx2TCXLovbjuRYUEGtyk8PfXB5U79LCIrPeVPpFtishrBiOEwNdASEwVJB5WPbcNIjN07NuqxKpAU1Hz3jLcKqEmm+M0rZSmg8rMcNVjobDKE93ulebbfoFS0yAEq0t4cMEtOurLtOTCqdErh72PYqZmr0FPbRE3SjmZBcSlkbHdbaymDQdlGH7Roq74eW5xVV8XwxCSifopTa7VM2cTqX2oN1P6WUKpVGx5nvv52C7xCQs4pHfMEGfh44boawc6DbxaL5+nx6UQp/rNw5RuOPbA3A/m/CxOMumQA63IsOeKRPJerjIQVdLRno7lMVDQrTVmad0fHBvJ8QoiiwsaUZgIl7fg/I+ZqF6ImSdOoOSd6du+5wg+8373+mOtXpLyY0REs69ZmJwc+fVhNgSXdfZYQePrOIZyWQCWD+dYKjPVpT0fcrJHUSYxAJvYHGMRGZ2PcAxYUjIWiSezZQQBBFDdLxKQdLlEwC1e5ZajxvFtSo+XyoyjHhsIk9jtuoKCHRcqRT3nI6AUGIC0
s9TFTaiiY9JwdpsbUVS4dUeOHNcMjKmfk6DqetoO79W+N0fp+RjYPSMAP1SUWKoBNaN9S8bK2L7GMd/UmNa+eXyB2XV/sxSyrGvRRm+X7iPYqTMEwqdSmSOXJFM24oy2oQbuFKq0jdWnnigLGAYqmZL0jtxvF8OAPuhSSdQFZOzUGE/B08J7rzjtTohYnrWEHjqr2kttp9I=

$ ssh $host
key_read: uudecode 
AAAAB3NzaC1kc3MAAAQBANWV7bN8pqNeMAzcANYR1FyvKYuOCNIwU/xI4htk3fAp+LG1aApwVHXyrqkMf2OwngSyzmaSJCya6fsUjla+0yPsT/KjS2/U0lHmyjzqX2AyKl3+0fPl4OH9ilMugXO3G5lqMeeb4A/ALRBRzw0w9WB10zBZxJvdLRUwdkvRTKynGAEUC08+Qo04enWINTp2dV6VW9Ghf+Miete4mb7dPJrnPk9MVAxJ5Sn5079Tx4j5MfAjAvBQWI4nJ/O59rz0w5ZuEo1Z7y7EV8JhNJj5ZfRszOyNau+IdD+/z5o8tDO2Zwkr5twfRJPo5sh6cRlJx2MHhO9W/2RAPXgEayzRCy5aTscgEAQru/KP6AyJ0hxmRKlP5+nNBI5qXRz+6oapJo+rV97TF25qrtTREN6HlPKuGqsvz6cf9g7gbRaAD2AB3p/Znmg9l3njHxTqG/A74L/KObVnfxZOA52FfATF/oQ7foxpUiBh27T3S+xmfbzeX+JpStpteQ+YnVL0fSb+osGwGSkxOy7PadQevhhvChWmCbgsRuaUoY3vY3bfTZ3yK3HO4kORIkODJ5YGReQxYDWinxII1dDAFvNazkicRGVJst2i33rmUkIs6nKC5RJH7SIQ+ks4t4adMUbd3LaC78RH0tsVkPDY20gNzwT2tcN4+ranFpYS1wyzcEbfbOAYsT/YNovFdBcVM3u3tGf5EoyCluao1R8Vg4r+e6WbcszHqIRLn3ATGNX55XLCem9QYTr0GBZwPKQnrDXlbEiNHKOArKIwV/6OPu1y5kowM9TOHy8D+kE+VbUvUCHfjNOm8Lc7ZgByYHKsrOe/piBGAGWzFSy/WTIyhlEapq6qlMpMhLuOXsdhaWnNUDsghArJWfHPigekbtfOBZGWq//V5FYLs8l17DIKzPVKqlZVoXK73/3RN+uUyomfLmP/Ww+4UObkQImC5LwtiziCIrDp5R+cjBF+Jb
tzEZ0k36N3dRUAThe 
authenticity of host '$host (213.144.148.202)' can't be established.
RSA key fingerprint is f5:dd:18:78:75:02:30:ec:49:e6:b4:77:db:32:ac:64.
Are you sure you want to continue connecting (yes/no)? 

...

or another try:
$ ssh $host -l $user
key_read: uudecode 
AAAAB3NzaC1kc3MAAAQBANWV7bN8pqNeMAzcANYR1FyvKYuOCNIwU/xI4htk3fAp+LG1aApwVHXyrqkMf2OwngSyzmaSJCya6fsUjla+0yPsT/KjS2/U0lHmyjzqX2AyKl3+0fPl4OH9ilMugXO3G5lqMeeb4A/ALRBRzw0w9WB10zBZxJvdLRUwdkvRTKynGAEUC08+Qo04enWINTp2dV6VW9Ghf+Miete4mb7dPJrnPk9MVAxJ5Sn5079Tx4j5MfAjAvBQWI4nJ/O59rz0w5ZuEo1Z7y7EV8JhNJj5ZfRszOyNau+IdD+/z5o8tDO2Zwkr5twfRJPo5sh6cRlJx2MHhO9W/2RAPXgEayzRCy5aTscgEAQru/KP6AyJ0hxmRKlP5+nNBI5qXRz+6oapJo+rV97TF25qrtTREN6HlPKuGqsvz6cf9g7gbRaAD2AB3p/Znmg9l3njHxTqG/A74L/KObVnfxZOA52FfATF/oQ7foxpUiBh27T3S+xmfbzeX+JpStpteQ+YnVL0fSb+osGwGSkxOy7PadQevhhvChWmCbgsRuaUoY3vY3bfTZ3yK3HO4kORIkODJ5YGReQxYDWinxII1dDAFvNazkicRGVJst2i33rmUkIs6nKC5RJH7SIQ+ks4t4adMUbd3LaC78RH0tsVkPDY20gNzwT2tcN4+ranFpYS1wyzcEbfbOAYsT/YNovFdBcVM3u3tGf5EoyCluao1R8Vg4r+e6WbcszHqIRLn3ATGNX55XLCem9QYTr0GBZwPKQnrDXlbEiNHKOArKIwV/6OPu1y5kowM9TOHy8D+kE+VbUvUCHfjNOm8Lc7ZgByYHKsrOe/piBGAGWzFSy/WTIyhlEapq6qlMpMhLuOXsdhaWnNUDsghArJWfHPigekbtfOBZGWq//V5FYLs8l17DIKzPVKqlZVoXK73/3RN+uUyomfLmP/Ww+4UObkQImC5LwtiziCIrDp5R+cjBF+Jb
tzEZ0k36N3dRUAEnter 
passphrase for key '/home/$user/.ssh/id_dsa':
$user@$host's password:

I think the key do not work at all.
:-/

Regards,


-- 
| kickino.org || logic-bomb.org || forkbomb.ch || herder-gymnasium.de |

<Slant> dpkg -i kernel-image-2.4.18_kami.1.0_i386.deb
<Sam|foo> ok
<Slant> ok, reboot.
<Sam|foo> brb
* Slant nods.
<-- Sam|foo has quit (QUIT: User exited)
<FlipTopBox> sucka.  he's doomed, isn't he.



From dtucker at zip.com.au  Wed Jul 20 00:58:13 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 20 Jul 2005 00:58:13 +1000
Subject: key_read: uudecode
In-Reply-To: <42DD0F7C.2040705@arcor.de>
References: <42DD0F7C.2040705@arcor.de>
Message-ID: <42DD1505.4010701@zip.com.au>

Sebastian Wieseler wrote:
> Hello guys, mabye this can help you somehow:
> 
> $ ssh-keygen -b 8192 -g -t dsa
[...]
> or another try:
> $ ssh $host -l $user
> key_read: uudecode 
> AAAAB3NzaC1kc3MAAAQBANWV7bN8pqNeMAzcANYR1FyvKYuOCNIwU/xI4htk3fAp+LG1aApwVHXyrqkMf2OwngSyzmaSJCya6fsUjla+0yPsT/KjS2/U0lHmyjzqX2AyKl3+0fPl4OH9ilMugXO3G5lqMeeb4A/ALRBRzw0w9WB10zBZxJvdLRUwdkvRTKynGAEUC08+Qo04enWINTp2dV6VW9Ghf+Miete4mb7dPJrnPk9MVAxJ5Sn5079Tx4j5MfAjAvBQWI4nJ/O59rz0w5ZuEo1Z7y7EV8JhNJj5ZfRszOyNau+IdD+/z5o8tDO2Zwkr5twfRJPo5sh6cRlJx2MHhO9W/2RAPXgEayzRCy5aTscgEAQru/KP6AyJ0hxmRKlP5+nNBI5qXRz+6oapJo+rV97TF25qrtTREN6HlPKuGqsvz6cf9g7gbRaAD2AB3p/Znmg9l3njHxTqG/A74L/KObVnfxZOA52FfATF/oQ7foxpUiBh27T3S+xmfbzeX+JpStpteQ+YnVL0fSb+osGwGSkxOy7PadQevhhvChWmCbgsRuaUoY3vY3bfTZ3yK3HO4kORIkODJ5YGReQxYDWinxII1dDAFvNazkicRGVJst2i33rmUkIs6nKC5RJH7SIQ+ks4t4adMUbd3LaC78RH0tsVkPDY20gNzwT2tcN4+ranFpYS1wyzcEbfbOAYsT/YNovFdBcVM3u3tGf5EoyCluao1R8Vg4r+e6WbcszHqIRLn3ATGNX55XLCem9QYTr0GBZwPKQnrDXlbEiNHKOArKIwV/6OPu1y5kowM9TOHy8D+kE+VbUvUCHfjNOm8Lc7ZgByYHKsrOe/piBGAGWzFSy/WTIyhlEapq6qlMpMhLuOXsdhaWnNUDsghArJWfHPigekbtfOBZGWq//V5FYLs8l17DIKzPVKqlZVoXK73/3RN+uUyomfLmP/Ww+4UObkQImC5LwtiziCIrDp5R+cjBF
+Jb
> tzEZ0k36N3dRUAEnter 
> passphrase for key '/home/$user/.ssh/id_dsa':
> $user@$host's password:

What version is this?  I think that was fixed a while back (in 4.0, I 
think).

-- 
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 senthilkumar_sen at hotpop.com  Wed Jul 20 02:28:49 2005
From: senthilkumar_sen at hotpop.com (Senthil Kumar)
Date: Tue, 19 Jul 2005 21:58:49 +0530
Subject: Pam module leaks information
References: <0b9101c589f1$2fb08b70$220110ac@sekco><42DB2CA0.8040608@zip.com.au><0e6601c58b84$10abb6c0$220110ac@sekco>
	<42DBBAEF.3030009@zip.com.au>
Message-ID: <25bb01c58c7f$051d51f0$220110ac@sekco>

 Darren wrote:
> That's a bit suspicious, are they checking the PAM service name or
> something?  Or is it password -> delay -> close connection?

password,delay and close connection.

> I added a timestamp option (-v) to my PAM test harness, this may help
> show where the delays are ocurring:
> http://www.zip.com.au/~dtucker/patches/#pamtest

When I run the PAM test harness with sshd and telnet I got diff. results and 
its given below,
with sshd:
./a.out -u senthil -s sshd
$Id: pam-test-harness.c,v 1.24 2005/07/18 14:10:35 dtucker Exp $
conversation struct {conv=0x4001900, appdata_ptr=0x400006cc}
pam_start(sshd, senthil, &conv, &pamh) = 0 (Success)
pam_set_item(pamh, PAM_TTY, "/dev/pts/ta") = 0 (Success)
pam_set_item(pamh, PAM_RHOST, "pluto") = 0 (Success)
pam_set_item(pamh, PAM_RUSER, "root") = 0 (Success)
pam_authenticate(pamh, 0)
    conversation called with 1 messages data 0x400006cc
        PROMPT_ECHO_OFF: Password: correct password        (No Time delay)
    conversation called with 1 messages data 0x400006cc
        ERROR_MSG: Your password will expire on Wed Jul 20 17:53:18 GMT 2005
 = 0 (Success)
pam_acct_mgmt(pamh, 0) = 7 (Permission denied)
pam_end(pamh, 0) = 0 (Success)

with telnet:
./a.out -u senthil -s telnetd
$Id: pam-test-harness.c,v 1.24 2005/07/18 14:10:35 dtucker Exp $
conversation struct {conv=0x4001900, appdata_ptr=0x400006cc}
pam_start(telnetd, senthil, &conv, &pamh) = 0 (Success)
pam_set_item(pamh, PAM_TTY, "/dev/pts/ta") = 0 (Success)
pam_set_item(pamh, PAM_RHOST, "pluto") = 0 (Success)
pam_set_item(pamh, PAM_RUSER, "root") = 0 (Success)
pam_authenticate(pamh, 0)
    conversation called with 1 messages data 0x400006cc
        PROMPT_ECHO_OFF: Password:  correct password.        (Time delay)
 = 9 (Authentication failed)
pam_end(pamh, 0) = 0 (Success)

For invalid passwd, both sshd and telnet have delay.

Thanks,
Senthil Kumar. 




From dtucker at zip.com.au  Wed Jul 20 12:10:55 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 20 Jul 2005 12:10:55 +1000
Subject: Pam module leaks information
In-Reply-To: <25bb01c58c7f$051d51f0$220110ac@sekco>
References: <0b9101c589f1$2fb08b70$220110ac@sekco><42DB2CA0.8040608@zip.com.au><0e6601c58b84$10abb6c0$220110ac@sekco>
	<42DBBAEF.3030009@zip.com.au>
	<25bb01c58c7f$051d51f0$220110ac@sekco>
Message-ID: <42DDB2AF.4030709@zip.com.au>

Senthil Kumar wrote:
> When I run the PAM test harness with sshd and telnet I got diff. results 
> and its given below,
> with sshd:
> ./a.out -u senthil -s sshd
> $Id: pam-test-harness.c,v 1.24 2005/07/18 14:10:35 dtucker Exp $
> conversation struct {conv=0x4001900, appdata_ptr=0x400006cc}
> pam_start(sshd, senthil, &conv, &pamh) = 0 (Success)
> pam_set_item(pamh, PAM_TTY, "/dev/pts/ta") = 0 (Success)
> pam_set_item(pamh, PAM_RHOST, "pluto") = 0 (Success)
> pam_set_item(pamh, PAM_RUSER, "root") = 0 (Success)
> pam_authenticate(pamh, 0)
>    conversation called with 1 messages data 0x400006cc
>        PROMPT_ECHO_OFF: Password: correct password        (No Time delay)
>    conversation called with 1 messages data 0x400006cc
>        ERROR_MSG: Your password will expire on Wed Jul 20 17:53:18 GMT 2005
> = 0 (Success)
> pam_acct_mgmt(pamh, 0) = 7 (Permission denied)
> pam_end(pamh, 0) = 0 (Success)
> 
> with telnet:
> ./a.out -u senthil -s telnetd

I'm not sure about HP-UX but you might need to use the "login" service.

> $Id: pam-test-harness.c,v 1.24 2005/07/18 14:10:35 dtucker Exp $
> conversation struct {conv=0x4001900, appdata_ptr=0x400006cc}
> pam_start(telnetd, senthil, &conv, &pamh) = 0 (Success)
> pam_set_item(pamh, PAM_TTY, "/dev/pts/ta") = 0 (Success)
> pam_set_item(pamh, PAM_RHOST, "pluto") = 0 (Success)
> pam_set_item(pamh, PAM_RUSER, "root") = 0 (Success)
> pam_authenticate(pamh, 0)
>    conversation called with 1 messages data 0x400006cc
>        PROMPT_ECHO_OFF: Password:  correct password.        (Time delay)
> = 9 (Authentication failed)
> pam_end(pamh, 0) = 0 (Success)

PAM is behaving differently in these cases, either because the service 
configuration is different or your PAM module is doing some kind of 
magic.  (note that in the sshd case, the authentication succeeds but the 
account check fails, whereas in the telnetd case the authentication fails).

You said earlier password auth exhibits the delay as expected, can you 
confirm that?

The output from "pam-test-harness -s sshd" is consistent with what 
you're observing in keyboard-interactive, ie there's no delay because 
PAM isn't inserting one.  If password auth isn't behaving the same way 
(remembering that it uses the same PAM service name) then I have no idea 
what's going on...

-- 
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 ctaylor at 4t-fi.com  Wed Jul 20 19:04:29 2005
From: ctaylor at 4t-fi.com (Chris Taylor)
Date: Wed, 20 Jul 2005 10:04:29 +0100
Subject: AIX 5.1 /etc/security/failedlogin entry with OpenSSH 4.1p1 
Message-ID: <F7E6270C1F2796448968AD08761B39661D85@exchange.4tfi.com>

Hello

Ive downloaded OpenSSH 4.1p1 from the portable openssh web pages...
Compiled it up for an AIX 5.1 host (with latest IBM maintenance patches
applied)
using defaults in all cases.

When doing a successful SSH authentication it places an entry into
/etc/security/failedlogin
as well as /var/adm/wtmp

Ive also tried adding "UseLogin yes" to the sshd_config
PAM ISNT configured (infact sshd says the UsePAM option in the config
file is illegal)

None of the other "access methods", for instance telnet add a
failedlogin entry
unless the user fails a password challenge.

Is this a bug ?

Attached below is the "script"...

Thanks...

	-Chris

========================================================================
==========================

Script command is started on Wed Jul 20 09:56:11 BST 2005.

# ssh localhost -l root
root at localhost's password: 
************************************************************************
*******
*
*
*
*
*  Welcome to AIX Version 5.1!
*
*
*
*
*
*  Please see the README file in /usr/lpp/bos for information pertinent
to    *
*  this release of the AIX Operating System.
*
*
*
*
*
************************************************************************
*******
1 unsuccessful login attempt since last login.
Last unsuccessful login: Wed Jul 20 09:56:25 BST 2005 on ssh from
localhost
Last login: Wed Jul 20 09:50:59 BST 2005 on /dev/pts/5 from x.x.x.x

# cd /etc/security
# /usr/sbin/acct/fwtmp < failedlogin
root                    ssh           7 21704 0000 0000 1121849785
localhost                        
	Wed Jul 20 09:56:25 BST 2005
# /usr/sbin/acct/fwtmp < /var/adm/wtmp
root     pts/7          pts/7         7 15394 0000 0000 1121849788
localhost                        
	Wed Jul 20 09:56:28 BST 2005
root     pts/7          pts/7         7 15394 0000 0000 1121849788
localhost                        
	Wed Jul 20 09:56:28 BST 2005
# 
Connection to localhost closed.

# 

Script command is complete on Wed Jul 20 09:57:01 BST 2005.

========================================================================
==========================



From dtucker at zip.com.au  Wed Jul 20 19:25:41 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 20 Jul 2005 19:25:41 +1000
Subject: AIX 5.1 /etc/security/failedlogin entry with OpenSSH 4.1p1
In-Reply-To: <F7E6270C1F2796448968AD08761B39661D85@exchange.4tfi.com>
References: <F7E6270C1F2796448968AD08761B39661D85@exchange.4tfi.com>
Message-ID: <42DE1895.4040604@zip.com.au>

Chris Taylor wrote:
> Ive downloaded OpenSSH 4.1p1 from the portable openssh web pages...
> Compiled it up for an AIX 5.1 host (with latest IBM maintenance patches
> applied) using defaults in all cases.
> 
> When doing a successful SSH authentication it places an entry into
> /etc/security/failedlogin
> as well as /var/adm/wtmp
> 
> Ive also tried adding "UseLogin yes" to the sshd_config
> PAM ISNT configured (infact sshd says the UsePAM option in the config
> file is illegal)
> 
> None of the other "access methods", for instance telnet add a
> failedlogin entry unless the user fails a password challenge.
> 
> Is this a bug ?

Possibly but I'm not sure.

Does the same thing happen if you set "PermitEmptyPasswords no" in 
sshd_config?  If that helps I'll explain...

-- 
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  Wed Jul 20 23:13:04 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 20 Jul 2005 23:13:04 +1000
Subject: AIX 5.1 /etc/security/failedlogin entry with OpenSSH 4.1p1
In-Reply-To: <42DE1895.4040604@zip.com.au>
References: <F7E6270C1F2796448968AD08761B39661D85@exchange.4tfi.com>
	<42DE1895.4040604@zip.com.au>
Message-ID: <42DE4DE0.3070307@zip.com.au>

Darren Tucker wrote:
> Chris Taylor wrote:
>>None of the other "access methods", for instance telnet add a
>>failedlogin entry unless the user fails a password challenge.
>>
>>Is this a bug ?
> 
> Possibly but I'm not sure.

Turns out that it is, but not were I suspected: it occurs when 
UsePrivilegeSeparation=no and ChallengeResponseAuthentication=yes and no 
kbdint drivers are present (ie sshd was not compiled with PAM support).

When the client tries keyboard-interactive it fails (obviously) but it's 
recorded as a failure.  The workaround is to set either 
ChallengeResponseAuthentication=no or UsePrivilegeSeparation=yes in 
sshd_config.

This could also occur on any platform using the record_failed_login hook 
(ie Unicos and the btmp logging functionality on Linux and HP-UX).

We need to fix this but I don't see an easy, obvious way at the moment.

-- 
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 senthilkumar_sen at hotpop.com  Fri Jul 22 01:01:09 2005
From: senthilkumar_sen at hotpop.com (Senthil Kumar)
Date: Thu, 21 Jul 2005 20:31:09 +0530
Subject: Pam module leaks information
References: <0b9101c589f1$2fb08b70$220110ac@sekco><42DB2CA0.8040608@zip.com.au><0e6601c58b84$10abb6c0$220110ac@sekco><42DBBAEF.3030009@zip.com.au><25bb01c58c7f$051d51f0$220110ac@sekco>
	<42DDB2AF.4030709@zip.com.au>
Message-ID: <2b7701c58e05$0a18df30$220110ac@sekco>

Darren Tucker wrote:
>
> I'm not sure about HP-UX but you might need to use the "login" service.

For login service pam_authenticate returns success as sshd.

./a.out -u senthil -s login
$Id: pam-test-harness.c,v 1.24 2005/07/18 14:10:35 dtucker Exp $
conversation struct {conv=0x4001900, appdata_ptr=0x400006cc}
pam_start(login, senthil, &conv, &pamh) = 0 (Success)
pam_set_item(pamh, PAM_TTY, "/dev/pts/ta") = 0 (Success)
pam_set_item(pamh, PAM_RHOST, "pluto") = 0 (Success)
pam_set_item(pamh, PAM_RUSER, "root") = 0 (Success)
pam_authenticate(pamh, 0)
   conversation called with 1 messages data 0x400006cc
        PROMPT_ECHO_OFF: Password: correct passwd  (no time delay)
  = 0 (Success)
pam_acct_mgmt(pamh, 0) = 7 (Permission denied)
pam_end(pamh, 0) = 0 (Success)

But with wrong pass there is a delay.

>
> PAM is behaving differently in these cases, either because the service
> configuration is different or your PAM module is doing some kind of
> magic.  (note that in the sshd case, the authentication succeeds but the
> account check fails, whereas in the telnetd case the authentication 
> fails).

I double checked by PAM configuration and they seems OK.

>
> You said earlier password auth exhibits the delay as expected, can you
> confirm that?

No I told its for telnet where it exhibits delay and close the connection 
but for sshd it closes immediately for password auth.
Here goes what is happening in my system,

With challengeresponse:
ssh -l senthil localhost
Password:      (correct pass) no delay
Password:      (wrong pass) delay
Password:      (correct pass) no delay

Without challengeresponse:
ssh -l senthil localhost
senthil at localhost's password: (correct pass) no delay
Connection closed by 127.0.0.1

ssh -l senthil localhost -p 1111
senthil at localhost's password: (wrong pass) delay.

Thanks,
Senthil Kumar.






From Peter_Losher at isc.org  Sun Jul 24 12:04:21 2005
From: Peter_Losher at isc.org (Peter Losher)
Date: Sat, 23 Jul 2005 19:04:21 -0700
Subject: Does OpenSSH+GSSAPI interoperate between Heimdal and MIT?
Message-ID: <200507231904.30142.Peter_Losher@isc.org>

I have a freshly installed FreeBSD 6.0-BETA1 system, which comes with Heimdal 
& OpenSSH w/GSSAPI enabled (version 4.1p1 FreeBSD-20050605)  Most of the 
servers I connect to have OpenSSH w/GSSAPI enabled but they use MIT Kerberos 
(1,3.x and 1.4.x)  Now, I can use ticket authentication between all systems 
where the libraries are all the same (Heimdal or MIT), but trying to use, for 
example, a client built w/ Heimdal and a server that is built w/ MIT, it 
fails w/ this error:

-=-
debug2: we sent a gssapi-with-mic packet, wait for reply
debug1:  Miscellaneous failure (see text)
PROCESS_TGS

debug1: Trying to start again
debug2: we did not send a packet, disable method
-=-

Has anyone experienced this, and if so, how did they get around it (if they 
did)?

Best Wishes - Peter
-- 
Peter_Losher at isc.org | ISC | OpenPGP 0xE8048D08 | "The bits must flow"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20050723/043d3416/attachment.bin 

From Sergio.Gelato at astro.su.se  Sun Jul 24 20:01:05 2005
From: Sergio.Gelato at astro.su.se (Sergio Gelato)
Date: Sun, 24 Jul 2005 12:01:05 +0200
Subject: Does OpenSSH+GSSAPI interoperate between Heimdal and MIT?
In-Reply-To: <200507231904.30142.Peter_Losher@isc.org>
References: <200507231904.30142.Peter_Losher@isc.org>
Message-ID: <20050724100104.GA9357@astro.su.se>

* Peter Losher [2005-07-23 19:04:21 -0700]:
> I have a freshly installed FreeBSD 6.0-BETA1 system, which comes with Heimdal 

Which version of Heimdal? 0.6 or 0.7?

With 0.6, there is at least one issue you need to pay attention to, involving
the des3 MIC algorithm. Older Heimdal had an over-the-wire incompatibility 
with MIT. This was fixed in 0.6, but not enabled by default until 0.7; if you
want to enable it, you need to add a

[gssapi]
	correct_des3_mic = *

to your krb5.conf. See the Heimdal documentation for further details, in
particular if you need to talk to pre-0.6 Heimdal. (The * is a regular
expression matching the service principal.)

I'm not sure that this is your problem, but there is a good chance...

> & OpenSSH w/GSSAPI enabled (version 4.1p1 FreeBSD-20050605)  Most of the 
> servers I connect to have OpenSSH w/GSSAPI enabled but they use MIT Kerberos 
> (1,3.x and 1.4.x)  Now, I can use ticket authentication between all systems 
> where the libraries are all the same (Heimdal or MIT), but trying to use, for 
> example, a client built w/ Heimdal and a server that is built w/ MIT, it 
> fails w/ this error:
> 
> -=-
> debug2: we sent a gssapi-with-mic packet, wait for reply
> debug1:  Miscellaneous failure (see text)
> PROCESS_TGS
> 
> debug1: Trying to start again
> debug2: we did not send a packet, disable method
> -=-
> 
> Has anyone experienced this, and if so, how did they get around it (if they 
> did)?
> 
> Best Wishes - Peter
> -- 
> Peter_Losher at isc.org | ISC | OpenPGP 0xE8048D08 | "The bits must flow"




From fraff at free.fr  Tue Jul 26 00:20:02 2005
From: fraff at free.fr (fraff)
Date: Mon, 25 Jul 2005 16:20:02 +0200
Subject: ssh -f won't detach properly when run from cron.
Message-ID: <20050725142002.GE7267@plouc.org>

Hi,

In file ssh.c, in function "ssh_session2", this piece of code:

/* If requested, let ssh continue in the background. */
if (fork_after_authentication_flag)
    if (daemon(1, 1) < 0)
        fatal("daemon() failed: %.200s", strerror(errno));

implements the "-f" option, but when run from cron, it does not detach
properly because of the second parameter (noclose) of the daemon() function.

The result is a defunct process and a CRON process waiting for ssh to
exit.

I don't understand why the "noclose" parameter of daemon() is set to
"1", could somebody explain ?

thanks for all.

-- 
fraff



From evaldo at gardenali.biz  Mon Jul 25 10:43:40 2005
From: evaldo at gardenali.biz (Evaldo Gardenali)
Date: Sun, 24 Jul 2005 21:43:40 -0300
Subject: file name handling "bug" in scp?
Message-ID: <42E435BC.3010902@gardenali.biz>

Hi

I think I found a small filename handling issue in scp:

evaldo at winston:~$ scp evaldo at 127.0.0.1:test-\`whoami\`-test .
Password:
scp: test-evaldo-test: No such file or directory
evaldo at winston:~$ scp evaldo at 127.0.0.1:test-\`echo\ foo\`-test .
Password:
scp: test-foo-test: No such file or directory
evaldo at winston:~$

evaldo at winston:~$ ssh -V
OpenSSH_3.9 NetBSD_Secure_Shell-20050213, OpenSSL 0.9.7d 17 Mar 2004

(yeah, I know I am going to be larted for using a non-pure ssh, but I 
tried it with the portable openssh under linux and netbsd too, and the 
same thing happened)

Evaldo Gardenali

Please CC me any replies, as I am not subscribed
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3965 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20050724/3ddb1839/attachment.bin 

From Peter_Losher at isc.org  Tue Jul 26 06:09:29 2005
From: Peter_Losher at isc.org (Peter Losher)
Date: Mon, 25 Jul 2005 13:09:29 -0700
Subject: Does OpenSSH+GSSAPI interoperate between Heimdal and MIT?
In-Reply-To: <20050724100104.GA9357@astro.su.se>
References: <200507231904.30142.Peter_Losher@isc.org>
	<20050724100104.GA9357@astro.su.se>
Message-ID: <200507251309.36419.Peter_Losher@isc.org>

On Sunday 24 July 2005 03:01 am, Sergio Gelato wrote:
> * Peter Losher [2005-07-23 19:04:21 -0700]:
> > I have a freshly installed FreeBSD 6.0-BETA1 system, which comes with
> > Heimdal
>
> Which version of Heimdal? 0.6 or 0.7?

0.6.3.

> With 0.6, there is at least one issue you need to pay attention to,
> involving the des3 MIC algorithm. Older Heimdal had an over-the-wire
> incompatibility with MIT. This was fixed in 0.6, but not enabled by default
> until 0.7; if you want to enable it, you need to add a
>
> [gssapi]
> 	correct_des3_mic = *
>
> to your krb5.conf. See the Heimdal documentation for further details, in
> particular if you need to talk to pre-0.6 Heimdal. (The * is a regular
> expression matching the service principal.)
>
> I'm not sure that this is your problem, but there is a good chance...

Thanks, with some tweaking (and reading 'man gssapi' on the system) it works:

-=-
[gssapi]
	correct_des3_mic = */*@*
-=-

Thanks for the pointer!

Best WIshes - Peter
-- 
Peter_Losher at isc.org | ISC | OpenPGP 0xE8048D08 | "The bits must flow"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20050725/8e4e20a9/attachment.bin 

From djm at mindrot.org  Tue Jul 26 08:08:12 2005
From: djm at mindrot.org (Damien Miller)
Date: Tue, 26 Jul 2005 08:08:12 +1000
Subject: ssh -f won't detach properly when run from cron.
In-Reply-To: <20050725142002.GE7267@plouc.org>
References: <20050725142002.GE7267@plouc.org>
Message-ID: <42E562CC.3080102@mindrot.org>

fraff wrote:
> Hi,
> 
> In file ssh.c, in function "ssh_session2", this piece of code:
> 
> /* If requested, let ssh continue in the background. */
> if (fork_after_authentication_flag)
>     if (daemon(1, 1) < 0)
>         fatal("daemon() failed: %.200s", strerror(errno));
> 
> implements the "-f" option, but when run from cron, it does not detach
> properly because of the second parameter (noclose) of the daemon() function.
> 
> The result is a defunct process and a CRON process waiting for ssh to
> exit.
> 
> I don't understand why the "noclose" parameter of daemon() is set to
> "1", could somebody explain ?

Because you may still want output from the backgrounded command.

Try ssh -nf ... >/dev/null 2>&1

-d



From dtucker at zip.com.au  Tue Jul 26 11:49:54 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 26 Jul 2005 11:49:54 +1000
Subject: file name handling "bug" in scp?
In-Reply-To: <42E435BC.3010902@gardenali.biz>
References: <42E435BC.3010902@gardenali.biz>
Message-ID: <42E596C2.7040508@zip.com.au>

Evaldo Gardenali wrote:
> I think I found a small filename handling issue in scp:
> 
> evaldo at winston:~$ scp evaldo at 127.0.0.1:test-\`whoami\`-test .
> Password:
> scp: test-evaldo-test: No such file or directory
> evaldo at winston:~$ scp evaldo at 127.0.0.1:test-\`echo\ foo\`-test .
> Password:
> scp: test-foo-test: No such file or directory
> evaldo at winston:~$

I don't follow, what did you expect?  Do the files "test-evaldo-test" 
and "test-foo-test" exist?

It behaves consistly with what I'd expect (remember: the shell expansion 
occurs twice: once by the client's shell and once by the server's).

-- 
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 evaldo at gardenali.biz  Tue Jul 26 12:33:07 2005
From: evaldo at gardenali.biz (Evaldo Gardenali)
Date: Mon, 25 Jul 2005 23:33:07 -0300
Subject: file name handling "bug" in scp?
In-Reply-To: <42E596C2.7040508@zip.com.au>
References: <42E435BC.3010902@gardenali.biz> <42E596C2.7040508@zip.com.au>
Message-ID: <42E5A0E3.8050102@gardenali.biz>

Hi

My point is... shouldn't scp prevent expansion in the remote side?
This allows users of sites that prevent them from logging in via ssh or 
running remote commands to abuse scp and actually run what they wanted.

Some people allow you to use scp/sftp to do file transfer, but not to 
run vanity commands on their servers. This happens a lot in companies I 
know.

Thanks for looking at it

Evaldo


Darren Tucker wrote:
> Evaldo Gardenali wrote:
>> I think I found a small filename handling issue in scp:
>>
>> evaldo at winston:~$ scp evaldo at 127.0.0.1:test-\`whoami\`-test .
>> Password:
>> scp: test-evaldo-test: No such file or directory
>> evaldo at winston:~$ scp evaldo at 127.0.0.1:test-\`echo\ foo\`-test .
>> Password:
>> scp: test-foo-test: No such file or directory
>> evaldo at winston:~$
> 
> I don't follow, what did you expect?  Do the files "test-evaldo-test" 
> and "test-foo-test" exist?
> 
> It behaves consistly with what I'd expect (remember: the shell expansion 
> occurs twice: once by the client's shell and once by the server's).
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3965 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20050725/4566f418/attachment.bin 

From dtucker at zip.com.au  Tue Jul 26 12:59:48 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 26 Jul 2005 12:59:48 +1000
Subject: file name handling "bug" in scp?
In-Reply-To: <42E5A0E3.8050102@gardenali.biz>
References: <42E435BC.3010902@gardenali.biz> <42E596C2.7040508@zip.com.au>
	<42E5A0E3.8050102@gardenali.biz>
Message-ID: <42E5A724.70309@zip.com.au>

Evaldo Gardenali wrote:
> My point is... shouldn't scp prevent expansion in the remote side?

It can't.  Since the file (or directory) name is passed as a 
command-line argument to the remote scp, it would require escaping the 
filename.   This is shell-specific, and scp has no knowledge of what the 
remote shell is going to do.

> This allows users of sites that prevent them from logging in via ssh or 
> running remote commands to abuse scp and actually run what they wanted.
[...]
> Some people allow you to use scp/sftp to do file transfer, but not to 
> run vanity commands on their servers. This happens a lot in companies I 
> know.

Those that do must be using some mechanism to allow only scp (eg a 
correctly configured general-purpose restricted shell, or a special 
purpose shell such as scponly or rssh).  If they process shell backticks 
then that's a problem with them.

sftp is less problematic in this regard since it's a well-defined 
protocol and doesn't require a shell to parse filenames at 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 rschubnell at paninfo.com  Tue Jul 26 18:00:26 2005
From: rschubnell at paninfo.com (rschubnell at paninfo.com)
Date: Tue, 26 Jul 2005 10:00:26 +0200
Subject: Reto Schubnell/Paninfo AG ist abwesend.
Message-ID: <OFA761577D.B51B763A-ONC125704A.002BFC7B-C125704A.002BFC7B@paninfo.com>

Ich werde ab  25.07.2005 nicht im B?ro sein. Ich kehre zur?ck am
02.08.2005.


Meine Stellvertretung ist durch Herrn Roger Zimmermann geregelt.
In Dringenden F?llen wenden Sie sich bitte an unsere Hotline

Hotline Paninfo: 01 / 805 14 99

Mails werden nicht weitergeleitet !


#####
Diese Email wurde durch verschiedene Security Mechanismen geprueft
und fuer sauber befunden.
Wenn Sie Interesse an diesen Security Checks haben,
nehmen Sie mit uns Kontakt auf. http://www.paninfo.com
#####



From errror at errror.org  Tue Jul 26 20:12:59 2005
From: errror at errror.org (Patrick Cernko)
Date: Tue, 26 Jul 2005 12:12:59 +0200
Subject: scp filename quoting
Message-ID: <42E60CAB.4040002@errror.org>

Hi,

I just made a patch to "correctly" support special characters in scp at
the remote side. First let me explain the problem:

# cd /tmp
# touch this is a test
# cp this\ is\ a\ test a\ test
# scp localhost:$PWD/a\ test this\ is\ a\ test
scp: /tmp/a: No such file or directory
scp: test: No such file or directory

but

# scp localhost:$PWD/a\\\ test this\ is\ a\ test
a test                              100%    0     0.0KB/s   00:00
errror at defiant:/tmp> ls a\ test -l
-rw-rw-r--  1 errror errror 0 2005-07-26 11:50 a test

So: As scp stringifies the remote side filename, ignoring special
characters like ' ', the remote side get the wrong arguments. The
correct way to go would be to redesign the scp client-server-protocol,
but this is not desired (see http://www.openssh.com/faq.html#2.10) and
would take years to reach all running server's implementations. A quiet
easier fix is, to "correctly" quote the filenames for the remote side.
Here an example with my patch scp client:

# scp -v localhost:$PWD/a\ test this\ is\ a\ test
Unquoted target: "/tmp/a test"
Quoted target = "/tmp/a\ test"
Executing: program /usr/bin/ssh host localhost, user (unspecified),
command scp -v -t /tmp/a\ test
a test                              100%    0     0.0KB/s   00:00

I made the patch against the version of openssh I am currently running
on Linux Debian/sarge (openssh-3.8.1p1). It worked fine. For your
convenience, I also adopted the patch to the current cvs head version of
scp.c, but I did not test nor even compiled it.

I would be happy to see the functionality integrated in further
releases. Maybe this should be wrapped into an non-default option to
avoid incompatibility with existing setups.

So, what do you, the developers, think of my patch?

P.S.: Before I started developing the patch, I also noticed that the
sftp program has the same problems.
-- 
Patrick Cernko | mailto:errror at errror.org | http://www.errror.org
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: openssh_3.8.1p1-scpclient_with_correct_filename_quoting.diff
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20050726/d1ff975f/attachment.ksh 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: openssh_cvshead-scpclient_with_correct_filename_quoting.diff
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20050726/d1ff975f/attachment-0001.ksh 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 257 bytes
Desc: OpenPGP digital signature
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20050726/d1ff975f/attachment.bin 

From david at 2gen.com  Wed Jul 27 07:08:11 2005
From: david at 2gen.com (David =?iso-8859-1?Q?H=E4rdeman?=)
Date: Tue, 26 Jul 2005 23:08:11 +0200
Subject: Linux in-kernel keys support
Message-ID: <20050726210810.GB14661@hardeman.nu>

Hi all,

I recently made a patch to openssh 4.1p1 to allow it to use the 
in-kernel key management provided by 2.6.12 or later Linux kernels.

I've attached the patch (which is still only a proof-of-concept, for 
instance its very verbose right now) to this mail.

Now, my question is, is this a completely insane idea and would (a later 
version of) the patch have a chance of making it into the portable 
version?

Also, in its current incarnation, the patch stores the unencrypted 
secret key in the kernel keyring meaning that its available to the user 
who added it....I'm not sure if that is a problem security-wise...

To compile:
Apply the patch to 4.1p1, run autoconf, make sure that the key-utils 
library from 
http://people.redhat.com/~dhowells/keyutils/keyutils-0.1.tar.bz2 is 
comiled and installed and also copy the keyutil.h header into the 
openssh src dir. Then run configure and compile.

To use:
First run "ssh-add -k" to add the key to the kernel keyring and then use 
ssh as usual...it will use any ssh keys it finds in the kernel keyring.

Feedback and flames welcome.

Regards,
David H?rdeman
david at 2gen.com

-------------- next part --------------
diff -ubr -x configure openssh-4.1p1/config.h.in openssh-4.1p1-hacked/config.h.in
--- openssh-4.1p1/config.h.in	2005-05-25 14:26:09.000000000 +0200
+++ openssh-4.1p1-hacked/config.h.in	2005-07-25 23:18:17.000000000 +0200
@@ -694,6 +694,9 @@
 /* Define to 1 if you have the <libgen.h> header file. */
 #undef HAVE_LIBGEN_H
 
+/* Define to 1 if you have the `keyutil' library (-lkeyutil). */
+#undef HAVE_LIBKEYUTIL
+
 /* Define to 1 if you have the `nsl' library (-lnsl). */
 #undef HAVE_LIBNSL
 
diff -ubr -x configure openssh-4.1p1/configure.ac openssh-4.1p1-hacked/configure.ac
--- openssh-4.1p1/configure.ac	2005-04-24 09:52:23.000000000 +0200
+++ openssh-4.1p1-hacked/configure.ac	2005-07-25 23:15:32.000000000 +0200
@@ -261,6 +261,7 @@
 	AC_DEFINE(LINK_OPNOTSUPP_ERRNO, EPERM)
 	AC_DEFINE(_PATH_BTMP, "/var/log/btmp", [log for bad login attempts])
 	AC_DEFINE(USE_BTMP, 1, [Use btmp to log bad logins])
+	AC_CHECK_LIB(keyutil, keyctl_read)
 	inet6_default_4in6=yes
 	case `uname -r` in
 	1.*|2.0.*)
diff -ubr -x configure openssh-4.1p1/key.c openssh-4.1p1-hacked/key.c
--- openssh-4.1p1/key.c	2004-11-05 10:42:29.000000000 +0100
+++ openssh-4.1p1-hacked/key.c	2005-07-25 22:13:45.000000000 +0200
@@ -545,6 +545,9 @@
 key_ssh_name(const Key *k)
 {
 	switch (k->type) {
+	case KEY_RSA1:
+		return "rsa1";
+		break;
 	case KEY_RSA:
 		return "ssh-rsa";
 		break;
@@ -698,6 +701,7 @@
 	type = key_type_from_name(ktype);
 
 	switch (type) {
+	case KEY_RSA1:
 	case KEY_RSA:
 		key = key_new(type);
 		if (buffer_get_bignum2_ret(&b, key->rsa->e) == -1 ||
@@ -762,6 +766,7 @@
 		buffer_put_bignum2(&b, key->dsa->g);
 		buffer_put_bignum2(&b, key->dsa->pub_key);
 		break;
+	case KEY_RSA1:
 	case KEY_RSA:
 		buffer_put_cstring(&b, key_ssh_name(key));
 		buffer_put_bignum2(&b, key->rsa->e);
diff -ubr -x configure openssh-4.1p1/key.h openssh-4.1p1-hacked/key.h
--- openssh-4.1p1/key.h	2003-11-17 11:18:23.000000000 +0100
+++ openssh-4.1p1-hacked/key.h	2005-07-23 22:32:17.000000000 +0200
@@ -47,6 +47,7 @@
 
 /* key is stored in external hardware */
 #define KEY_FLAG_EXT		0x0001
+#define KEY_FLAG_KERN		0x0002
 
 struct Key {
 	int	 type;
diff -ubr -x configure openssh-4.1p1/ssh-add.c openssh-4.1p1-hacked/ssh-add.c
--- openssh-4.1p1/ssh-add.c	2005-03-14 13:08:12.000000000 +0100
+++ openssh-4.1p1-hacked/ssh-add.c	2005-07-25 23:22:08.000000000 +0200
@@ -48,6 +48,9 @@
 #include "authfile.h"
 #include "pathnames.h"
 #include "misc.h"
+#ifdef HAVE_LIBKEYUTIL
+#include "keyutil.h"
+#endif
 
 /* argv0 */
 extern char *__progname;
@@ -66,6 +69,9 @@
 /* User has to confirm key use */
 static int confirm = 0;
 
+/* Should we work on the in-kernel keyring */
+static int inkernel = 0;
+
 /* we keep a cache of one passphrases */
 static char *pass = NULL;
 static void
@@ -85,6 +91,26 @@
 	char *comment = NULL;
 	int ret = -1;
 
+#ifdef HAVE_LIBKEYUTIL
+	if (inkernel) {
+		char buf[MAXPATHLEN + 5];
+		
+		sprintf(buf, "ssh:%s", filename);
+		ret = keyctl_search(KEY_SPEC_USER_SESSION_KEYRING, "user", buf, 0);
+		if (ret < 0) {
+			printf("In-kernel key %s not found\n", filename);
+			return -1;
+		}
+
+		if (keyctl_unlink((key_serial_t) ret, KEY_SPEC_USER_SESSION_KEYRING) < 0) {
+			printf("Error when removing in-kernel key %d\n", ret);
+			return -1;
+		}
+		
+		fprintf(stderr, "In-kernel key %d (%s) removed\n", ret, filename);
+		return 0;
+	}
+#endif
 	public = key_load_public(filename, &comment);
 	if (public == NULL) {
 		printf("Bad key file %s\n", filename);
@@ -108,6 +134,65 @@
 {
 	int ret = -1;
 
+#ifdef HAVE_LIBKEYUTIL
+	if (inkernel) {
+		int count, dlen;
+		char *buf;
+		key_serial_t key, *keylist, *pk;
+		
+		count = keyctl_read_alloc(KEY_SPEC_USER_SESSION_KEYRING, (void **) &keylist);
+		if (count < 0) {
+			printf("Error in keyctl_read_alloc\n");
+			return -1;
+		}
+
+		count /= sizeof(key_serial_t);
+		pk = keylist;
+		ret = 0;
+		while (count--) {
+			key = *pk++;
+
+			if (keyctl_describe_alloc(key, &buf) < 0) {
+				printf("In-kernel key %d inaccessible\n", key);
+				ret = -1;
+				continue;
+			}
+
+			/* Is this a user key? */
+			if (strncmp(buf, "user;", strlen("user;")))
+				goto out;
+
+			dlen = -1;
+			sscanf(buf, "%*[^;];%*[^;];%*[^;];%*[^;];%n", &dlen);		
+			if (dlen == -1) {
+				printf("Unparseable description for in-kernel key %d\n", key);
+				ret = -1;
+				goto out;
+			}
+
+			/* Is this a ssh key? */
+			if (strncmp(buf + dlen, "ssh:", strlen("ssh:")))
+				goto out;
+			
+			
+			if (keyctl_unlink((key_serial_t) key, KEY_SPEC_USER_SESSION_KEYRING) < 0) {
+				ret = -1;
+				printf("Error when removing in-kernel key %d\n", key);
+			}
+			
+			out:
+			free(buf);	
+		};
+
+		free(keylist);
+		if (ret == 0)
+			fprintf(stderr, "All in-kernel identities removed.\n");
+		else
+			fprintf(stderr, "Failed to remove all in-kernel identities.\n");
+		return ret;
+	}
+#endif
+
 	if (ssh_remove_all_identities(ac, 1))
 		ret = 0;
 	/* ignore error-code for ssh2 */
@@ -162,6 +247,29 @@
 		}
 	}
 
+#ifdef HAVE_LIBKEYUTIL
+	if (inkernel) {
+		u_char *blob;
+		u_int len;
+		
+		xfree(comment);
+		comment = xmalloc(strlen(filename) + strlen("ssh:") + 1);
+		sprintf(comment, "ssh:%s", filename);
+
+		fprintf(stderr, "Adding key %s\n", key_fingerprint(private, SSH_FP_MD5, SSH_FP_HEX));	
+		if (!key_to_blob(private, &blob, &len))
+			fatal("key_to_blob: %s\n", filename);
+
+		if (add_key("user", comment, blob, len, KEY_SPEC_USER_SESSION_KEYRING) < 0)
+			fatal("Failed to add key: %s\n", filename);
+
+		xfree(comment);
+		key_free(private);
+		
+		ret = 0;
+		return ret;
+	}
+#endif
 	if (ssh_add_identity_constrained(ac, private, comment, lifetime,
 	    confirm)) {
 		fprintf(stderr, "Identity added: %s (%s)\n", filename, comment);
@@ -216,6 +324,91 @@
 	int had_identities = 0;
 	int version;
 
+#ifdef HAVE_LIBKEYUTIL
+	if (inkernel) {
+		int count, dlen;
+		char *buf;
+		u_char *buf2;
+		key_serial_t kkey, *keylist, *pk;
+		int ret = 0;
+		
+		count = keyctl_read_alloc(KEY_SPEC_USER_SESSION_KEYRING, (void **) &keylist);
+		if (count < 0) {
+			printf("Error in keyctl_read_alloc\n");
+			return -1;
+		}
+
+		count /= sizeof(key_serial_t);
+		pk = keylist;
+		while (count--) {
+			kkey = *pk++;
+
+			if (keyctl_describe_alloc(kkey, &buf) < 0) {
+				printf("In-kernel key %d inaccessible\n", kkey);
+				ret = -1;
+				continue;
+			}
+
+			/* Is this a user key? */
+			if (strncmp(buf, "user;", strlen("user;")))
+				goto out;
+
+			dlen = -1;
+			sscanf(buf, "%*[^;];%*[^;];%*[^;];%*[^;];%n", &dlen);		
+			if (dlen == -1) {
+				printf("Unparseable description for in-kernel key %d\n", kkey);
+				ret = -1;
+				goto out;
+			}
+
+			/* Is this a ssh key? */
+			if (strncmp(buf + dlen, "ssh:", strlen("ssh:")))
+				goto out;
+			
+			had_identities = 1;
+			comment = buf + dlen;
+			printf("In-kernel key %d (%s)\n", kkey, comment);
+			
+			ret = keyctl_read_alloc(kkey, (void **) &buf2);
+			if (ret < 1) {
+				fprintf(stderr, "Error in keyctl_read_alloc\n");
+				goto out;
+			}
+
+			key = key_from_blob(buf2, ret);
+			free(buf2);
+			if (!key) {
+				fprintf(stderr, "key_from_blob failed: %s\n", comment);
+				goto out;
+			}
+			key->flags = KEY_FLAG_KERN;
+			
+			if (do_fp) {
+				fp = key_fingerprint(key, SSH_FP_MD5,
+				    SSH_FP_HEX);
+				printf("%d %s %s (%s)\n",
+				    key_size(key), fp, comment, key_type(key));
+				xfree(fp);
+			} else {
+				if (!key_write(key, stdout))
+					fprintf(stderr, "key_write failed");
+				fprintf(stdout, " %s\n", comment);
+			}
+			key_free(key);	
+			
+			out:
+			free(buf);	
+		};
+
+		free(keylist);
+		if (!had_identities) {
+			printf("The kernel has no identities.\n");
+			return -1;
+		}
+		return ret;
+	}
+#endif
+
 	for (version = 1; version <= 2; version++) {
 		for (key = ssh_get_first_identity(ac, &comment, version);
 		    key != NULL;
@@ -297,6 +490,9 @@
 	fprintf(stderr, "  -X          Unlock agent.\n");
 	fprintf(stderr, "  -t life     Set lifetime (in seconds) when adding identities.\n");
 	fprintf(stderr, "  -c          Require confirmation to sign using identities\n");
+#ifdef HAVE_LIBKEYUTIL
+	fprintf(stderr, "  -k          Work on kernel keyring instead of agent keyring.\n");
+#endif
 #ifdef SMARTCARD
 	fprintf(stderr, "  -s reader   Add key in smartcard reader.\n");
 	fprintf(stderr, "  -e reader   Remove key in smartcard reader.\n");
@@ -307,7 +503,7 @@
 main(int argc, char **argv)
 {
 	extern char *optarg;
-	extern int optind;
+	extern int optind, opterr;
 	AuthenticationConnection *ac = NULL;
 	char *sc_reader_id = NULL;
 	int i, ch, deleting = 0, ret = 0;
@@ -318,13 +514,34 @@
 
 	SSLeay_add_all_algorithms();
 
-	/* At first, get a connection to the authentication agent. */
+#ifdef HAVE_LIBKEYUTIL
+	/* At first, check if we are working on the kernel or agent keys */
+	opterr = 0;
+	while ((ch = getopt(argc, argv, "lLcdDxXe:s:t:k")) != -1) {
+		switch (ch) {
+		case 'k':
+			inkernel = 1;
+			break;
+		default:
+			break;
+		}
+	}
+#endif
+
+	if (!inkernel) {
+		/* Get a connection to the authentication agent. */
 	ac = ssh_get_authentication_connection();
 	if (ac == NULL) {
-		fprintf(stderr, "Could not open a connection to your authentication agent.\n");
+			fprintf(stderr, 
+				"Could not open a connection to your authentication agent.\n");
 		exit(2);
 	}
-	while ((ch = getopt(argc, argv, "lLcdDxXe:s:t:")) != -1) {
+	}
+
+	/* Parse options again */
+	optind = 1;
+	opterr = 1;
+	while ((ch = getopt(argc, argv, "lLcdDxXe:s:t:k")) != -1) {
 		switch (ch) {
 		case 'l':
 		case 'L':
@@ -363,12 +580,25 @@
 				goto done;
 			}
 			break;
+		case 'k':
+			break;
 		default:
 			usage();
 			ret = 1;
 			goto done;
 		}
 	}
+
+	if (inkernel && sc_reader_id != NULL) {
+		fprintf(stderr, "Cannot use smart card reader with in-kernel keys\n");
+		ret = 1;
+		goto done;
+	} else if (inkernel && confirm) {
+		fprintf(stderr, "Cannot use confirmation with in-kernel keys\n");
+		ret = 1;
+		goto done;
+	}
+	
 	argc -= optind;
 	argv += optind;
 	if (sc_reader_id != NULL) {
@@ -410,6 +640,7 @@
 	clear_pass();
 
 done:
+	if (ac != NULL)
 	ssh_close_authentication_connection(ac);
 	return ret;
 }
diff -ubr -x configure openssh-4.1p1/ssh.c openssh-4.1p1-hacked/ssh.c
--- openssh-4.1p1/ssh.c	2005-05-04 07:33:09.000000000 +0200
+++ openssh-4.1p1-hacked/ssh.c	2005-07-25 23:29:10.000000000 +0200
@@ -73,6 +73,10 @@
 #include "monitor_fdpass.h"
 #include "uidswap.h"
 
+#ifdef HAVE_LIBKEYUTIL
+#include "keyutil.h"
+#endif
+
 #ifdef SMARTCARD
 #include "scard.h"
 #endif
@@ -1211,15 +1215,18 @@
 load_public_identity_files(void)
 {
 	char *filename;
-	int i = 0;
+	int i = 0, count;
 	Key *public;
+#ifdef HAVE_LIBKEYUTIL
+	key_serial_t *keylist;
+#endif
 #ifdef SMARTCARD
 	Key **keys;
 
 	if (options.smartcard_device != NULL &&
 	    options.num_identity_files < SSH_MAX_IDENTITY_FILES &&
 	    (keys = sc_get_keys(options.smartcard_device, NULL)) != NULL ) {
-		int count = 0;
+		count = 0;
 		for (i = 0; keys[i] != NULL; i++) {
 			count++;
 			memmove(&options.identity_files[1], &options.identity_files[0],
@@ -1246,6 +1253,95 @@
 		options.identity_files[i] = filename;
 		options.identity_keys[i] = public;
 	}
+
+#ifdef HAVE_LIBKEYUTIL
+	count = keyctl_read_alloc(KEY_SPEC_USER_SESSION_KEYRING, (void **)&keylist);
+	if (count < 0) {
+		fprintf(stderr, "Error in keyctl_read_alloc\n");
+		count = 0;
+	} else {
+		key_serial_t key, *pk;
+		char *buf;
+		int dlen, ret;
+
+		count /= sizeof(key_serial_t);
+		fprintf(stderr, "Count is %d\n", count);
+		if (count == 0)
+			fprintf(stderr, "Keychain empty\n");
+
+		pk = keylist;
+		for (; count > 0; count--) {
+			key = *pk++;
+			
+			ret = keyctl_describe_alloc(key, &buf);
+			if (ret < 0) {
+				printf("%9d: key inaccessible (%m)\n", key);
+				continue;
+			}
+
+			if (strncmp(buf, "user;", strlen("user;"))) {
+				fprintf(stderr, "%d: Not a user key\n", key);
+				goto out;
+			}
+
+			dlen = -1;	
+			sscanf(buf, "%*[^;];%*[^;];%*[^;];%*[^;];%n", &dlen);
+			if (dlen == -1) {
+				fprintf(stderr, "Unparseable description obtained for key %d\n", key);
+				goto out;
+			}
+		
+			fprintf(stderr, "Key %d with desc %s\n", key, buf + dlen);
+
+			if (strncmp(buf + dlen, "ssh:", strlen("ssh:"))) {
+				fprintf(stderr, "%d: Not a ssh key\n", key);
+				goto out;
+			}
+	
+			if (i < SSH_MAX_IDENTITY_FILES) {
+				char kname[1024];
+				
+				fprintf(stderr, "Adding key %d with desc %s\n", key, buf + dlen);
+				
+				/* Get the key payload */
+				free(buf);
+				ret = keyctl_read_alloc(key, (void **) &buf);
+				if (ret < 1) {
+					fprintf(stderr, "Error in keyctl_read_alloc\n");
+					continue;
+				}
+				public = key_from_blob((u_char *)buf, (u_int)ret);
+				free(buf);
+				if (!public)
+					continue;
+				public->flags = KEY_FLAG_KERN;
+fprintf(stderr, "Adding key %s\n", key_fingerprint(public, SSH_FP_MD5, SSH_FP_HEX));
+
+				/* Prepare the key description */
+				if (snprintf(kname, 1024, "%s:kernel key %d", key_ssh_name(public), key) < 1) {
+					fprintf(stderr, "Error in snprintf\n");
+					key_free(public);
+					continue;
+				}
+
+				/* Add the key */
+				memmove(&options.identity_files[1], &options.identity_files[0],
+					sizeof(char *) * (SSH_MAX_IDENTITY_FILES - 1));
+				memmove(&options.identity_keys[1], &options.identity_keys[0],
+					sizeof(Key *) * (SSH_MAX_IDENTITY_FILES - 1));
+				options.identity_keys[0] = public;
+				options.identity_files[0] = xstrdup(kname);
+				options.num_identity_files++;
+				if (options.num_identity_files > SSH_MAX_IDENTITY_FILES)
+					options.num_identity_files = SSH_MAX_IDENTITY_FILES;
+			}
+			
+			continue;
+			out:
+			free(buf);
+		}
+	}
+#endif /* LIBKEYUTIL */
 }
 
 static void
diff -ubr -x configure openssh-4.1p1/sshconnect1.c openssh-4.1p1-hacked/sshconnect1.c
--- openssh-4.1p1/sshconnect1.c	2004-08-12 14:40:25.000000000 +0200
+++ openssh-4.1p1-hacked/sshconnect1.c	2005-07-25 23:37:13.000000000 +0200
@@ -240,7 +240,7 @@
 	 * load the private key.  Try first with empty passphrase; if it
 	 * fails, ask for a passphrase.
 	 */
-	if (public->flags & KEY_FLAG_EXT)
+	if (public->flags & (KEY_FLAG_EXT | KEY_FLAG_KERN))
 		private = public;
 	else
 		private = key_load_private_type(KEY_RSA1, authfile, "", NULL);
diff -ubr -x configure openssh-4.1p1/sshconnect2.c openssh-4.1p1-hacked/sshconnect2.c
--- openssh-4.1p1/sshconnect2.c	2004-06-15 02:30:09.000000000 +0200
+++ openssh-4.1p1-hacked/sshconnect2.c	2005-07-23 22:39:24.000000000 +0200
@@ -832,7 +832,9 @@
 	 * we have already loaded the private key or
 	 * the private key is stored in external hardware
 	 */
-	if (id->isprivate || (id->key->flags & KEY_FLAG_EXT))
+	if(id->key->flags & KEY_FLAG_KERN)
+		fprintf(stderr, "Going to use kernel key\n");
+	if (id->isprivate || (id->key->flags & KEY_FLAG_EXT) || (id->key->flags & KEY_FLAG_KERN))
 		return (key_sign(id->key, sigp, lenp, data, datalen));
 	/* load the private key from the file */
 	if ((prv = load_identity_file(id->filename)) == NULL)

From djm at mindrot.org  Wed Jul 27 10:07:04 2005
From: djm at mindrot.org (Damien Miller)
Date: Wed, 27 Jul 2005 10:07:04 +1000 (EST)
Subject: Linux in-kernel keys support
In-Reply-To: <20050726210810.GB14661@hardeman.nu>
References: <20050726210810.GB14661@hardeman.nu>
Message-ID: <Pine.BSO.4.63.0507271005370.14926@fuyu.mindrot.org>

On Tue, 26 Jul 2005, DavidH?rdeman wrote:

> Hi all,
>
> I recently made a patch to openssh 4.1p1 to allow it to use the 
> in-kernel key management provided by 2.6.12 or later Linux kernels.

I'm not sure I understand this: just the patch just make ssh store and 
retrieve user authentication pubkeys from the kernel key store? It doesn't 
appear to any kernel facilities to do the actual signing of challenges.

-d

From bob at proulx.com  Wed Jul 27 15:20:45 2005
From: bob at proulx.com (Bob Proulx)
Date: Tue, 26 Jul 2005 23:20:45 -0600
Subject: file name handling "bug" in scp?
In-Reply-To: <42E435BC.3010902@gardenali.biz>
References: <42E435BC.3010902@gardenali.biz>
Message-ID: <20050727052045.GA16873@dementia.proulx.com>

Evaldo Gardenali wrote:
> I think I found a small filename handling issue in scp:
> [...concerning special shell characters not being escaped and files
> that contain those characters causing trouble...]

I suggest you use rsync with ssh to copy files in this instance.  The
remote shell only invokes the other half of the rsync program.  And
after that the shell is not involved in the transfer.

Bob



From david at 2gen.com  Wed Jul 27 20:20:15 2005
From: david at 2gen.com (David =?UTF-8?Q?H=C3=A4rdeman?=)
Date: Wed, 27 Jul 2005 12:20:15 +0200
Subject: Linux in-kernel keys support
In-Reply-To: <Pine.BSO.4.63.0507271005370.14926@fuyu.mindrot.org>
Message-ID: <20050727.ZQI.76667500@www.hardeman.nu>

Damien Miller (djm at mindrot.org) wrote:
> On Tue, 26 Jul 2005, David wrote:
>
> > Hi all,
> >
> > I recently made a patch to openssh 4.1p1 to allow it to use the
> > in-kernel key management provided by 2.6.12 or later Linux kernels.
>
> I'm not sure I understand this: just the patch just make ssh store and
> retrieve user authentication pubkeys from the kernel key store? It doesn't
> appear to any kernel facilities to do the actual signing of challenges.
>
> -d

Ummm, sorry if my first mail was unclear...

The patch allows ssh-add to (optionally) store the secret ssh keys in the
Linux kernel key storage. The key storage facility has no concept of signing
challenges etc, so ssh is also patched to read the keys from the kernel key
storage and to use them directly (much like it would read your keys from the
.ssh dir if you would run ssh with no ssh-agent running)

So the advantage is mainly that you can keep a bunch of ssh keys around
without having to keep track of any ssh-agents (in my case, I wanted the ssh
keys to be auto-loaded using udev when I inserted a usb-key, esentially using
it as a cheaper smartcard). This also means that if you add keys during an X
session and then continue to work on the console and log out of X, the keys
will still be available. Also, as the keys are stored in the user session
keyring, they are automatically wiped when the user is no longer logged into
the computer.

The disadvantage is that the kernel key storage doesnt support two things that
the agent supports: signing challenges and asking for confirmation before
allowing the use of a key. The former implies that secret keys are readable
(by the user who added them) from the kernel which might not be wise from a
security point-of-view.

On the other hand, if someone was to break into your account, and thus was
able to read the secret keys from the kernel....I imagine that he/she could
already do similar things by reading the memory of the ssh-agent and/or using
it to log into other machines...

I hope that cleared things up a bit...now, is the idea somewhat sane or is it
whack?

//David



From djm at mindrot.org  Wed Jul 27 20:51:55 2005
From: djm at mindrot.org (Damien Miller)
Date: Wed, 27 Jul 2005 20:51:55 +1000
Subject: Linux in-kernel keys support
In-Reply-To: <20050727.ZQI.76667500@www.hardeman.nu>
References: <20050727.ZQI.76667500@www.hardeman.nu>
Message-ID: <42E7674B.7000900@mindrot.org>

David H?rdeman wrote:

> The disadvantage is that the kernel key storage doesnt support two things that
> the agent supports: signing challenges and asking for confirmation before
> allowing the use of a key. The former implies that secret keys are readable
> (by the user who added them) from the kernel which might not be wise from a
> security point-of-view.

Yes, that is the point of the agent - you can load your private keys in,
but not get them out.

> On the other hand, if someone was to break into your account, and thus was
> able to read the secret keys from the kernel....I imagine that he/she could
> already do similar things by reading the memory of the ssh-agent and/or using
> it to log into other machines...

We take steps to avoid attackers reading keys out: we prevent coredumps
and ptrace of the agent process. To prevent others accessing the agent
it checks that uid of the user making requests on it matches the one who
started it.

This doesn't help so much against a hostile root, but they could grovel
keys out of /dev/kmem anyway (this is where hardware tokens come in).

An attacker who breaks your account can still log in using the agent
that is there, but I guess that is a little better than being able to
take your keys away to continue their attacks at their leisure. To
reduce this risk further you can run with key restrictions, like
confirm-on-use ("ssh-add -c ..." - highly recommended).

> I hope that cleared things up a bit...now, is the idea somewhat sane or is it
> whack?

Well, unless the kernel gets challenge-signing capabilities, then you
would be sacrificing security because an who breaks your account can
read your private keys.

OTOH, if the kernel gets the ability to sign challenges then we could
treat it as a hardware token using the existing OpenSC code. Writing a
token interface to the kernel keystore would be a really cool project
for someone interested.

If you are frustrated by managing keys between lots of agents, then you
can ask it to puts its SSH_AUTH_SOCK in a well-known place using (e.g.)
"ssh-agent -a ~/.ssh/agent-sock"

-d



From maillists.stdout at gmail.com  Wed Jul 27 21:08:18 2005
From: maillists.stdout at gmail.com (stdout azi)
Date: Wed, 27 Jul 2005 13:08:18 +0200
Subject: file name handling "bug" in scp?
In-Reply-To: <20050727052045.GA16873@dementia.proulx.com>
References: <42E435BC.3010902@gardenali.biz>
	<20050727052045.GA16873@dementia.proulx.com>
Message-ID: <e5f0f62c05072704084a92c76c@mail.gmail.com>

OK, let me mention my issue  :-)

$scp foo.pdf azi at foo.bar.com LALALALA
cp : cannot stat `azi at foo.bar.com': No such file or directory
$

Now, the file LALALALA is created and has the same content that foo.pdf

$ls -al
-rw-r--r--    1 azi      users           101 Aug  2 13:03 foo.pdf
-rw-r--r--    1 azi      users           101 Aug  2 13:03 LALALALA







On 7/27/05, Bob Proulx <bob at proulx.com> wrote:
> Evaldo Gardenali wrote:
> > I think I found a small filename handling issue in scp:
> > [...concerning special shell characters not being escaped and files
> > that contain those characters causing trouble...]
> 
> I suggest you use rsync with ssh to copy files in this instance.  The
> remote shell only invokes the other half of the rsync program.  And
> after that the shell is not involved in the transfer.
> 
> Bob
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>



From dtucker at zip.com.au  Wed Jul 27 22:01:12 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 27 Jul 2005 22:01:12 +1000
Subject: file name handling "bug" in scp?
In-Reply-To: <e5f0f62c05072704084a92c76c@mail.gmail.com>
References: <42E435BC.3010902@gardenali.biz>	<20050727052045.GA16873@dementia.proulx.com>
	<e5f0f62c05072704084a92c76c@mail.gmail.com>
Message-ID: <42E77788.3090404@zip.com.au>

stdout azi wrote:
> OK, let me mention my issue  :-)
> 
> $scp foo.pdf azi at foo.bar.com LALALALA
> cp : cannot stat `azi at foo.bar.com': No such file or directory

When scp is not given a hostname it falls back to behaving like cp and a 
3-arg cp works like that (although gnu cp checks that the destination is 
a directory):

$ echo foo >a
$ mkdir b
$ cp a foo at bar b
cp: cannot stat `foo at bar': No such file or directory
$ cat b/a
foo

-- 
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 rapier at psc.edu  Thu Jul 28 00:33:09 2005
From: rapier at psc.edu (Chris Rapier)
Date: Wed, 27 Jul 2005 10:33:09 -0400
Subject: New SCP? was Re: file name handling "bug" in scp?
In-Reply-To: <42E77788.3090404@zip.com.au>
References: <42E435BC.3010902@gardenali.biz>	<20050727052045.GA16873@dementia.proulx.com>	<e5f0f62c05072704084a92c76c@mail.gmail.com>
	<42E77788.3090404@zip.com.au>
Message-ID: <42E79B25.7060009@psc.edu>



Darren Tucker wrote:
> stdout azi wrote:
> 
>>OK, let me mention my issue  :-)
>>
>>$scp foo.pdf azi at foo.bar.com LALALALA
>>cp : cannot stat `azi at foo.bar.com': No such file or directory
> 
> 
> When scp is not given a hostname it falls back to behaving like cp and a 
> 3-arg cp works like that (although gnu cp checks that the destination is 
> a directory):

I guess this leads to the question: While SCP has always in the past 
fallen back to acting like cp because that is what rcp did, is this 
still necessary? I'm not, in anyway, suggesting that scp be 
fundamentally changed though. I'm just curious is there might be a place 
for something like 'scp2' (or 'scp+' or 'thatcrazynewwackytypeofscp'). 
I'm thinking of something that has similar functionality to scp but has 
enhanced functionality (parallel data streams, having a data and a 
control channel to handle multiple files more gracefully, etc etc etc). 
Any thoughts on this?



From david at 2gen.com  Thu Jul 28 07:22:20 2005
From: david at 2gen.com (David =?iso-8859-1?Q?H=E4rdeman?=)
Date: Wed, 27 Jul 2005 23:22:20 +0200
Subject: Linux in-kernel keys support
In-Reply-To: <42E7674B.7000900@mindrot.org>
References: <20050727.ZQI.76667500@www.hardeman.nu>
	<42E7674B.7000900@mindrot.org>
Message-ID: <20050727212219.GA31578@hardeman.nu>

On Wed, Jul 27, 2005 at 08:51:55PM +1000, Damien Miller wrote:
>David H?rdeman wrote:
>
>>The disadvantage is that the kernel key storage doesnt support two things 
>>that
>>the agent supports: signing challenges and asking for confirmation before
>>allowing the use of a key. The former implies that secret keys are readable
>>(by the user who added them) from the kernel which might not be wise from a
>>security point-of-view.
>
>Yes, that is the point of the agent - you can load your private keys in,
>but not get them out.
>

Understood...and with time, it might be possible to get the same kind of 
functionality into the kernel...I've seen patches by David Howells which 
add RSA signing capabilities to the kernel (as part of the modsign 
patch, see http://people.redhat.com/dhowells/modsign/). If the RSA part 
would be added along with parts of the MPI math library, it should be 
quite trivial to also add DSA and then all ssh1 and ssh2 key types would 
be supported unless I'm mistaken.

>>On the other hand, if someone was to break into your account, and thus was
>>able to read the secret keys from the kernel....I imagine that he/she could
>>already do similar things by reading the memory of the ssh-agent and/or 
>>using
>>it to log into other machines...
>
>We take steps to avoid attackers reading keys out: we prevent coredumps
>and ptrace of the agent process. To prevent others accessing the agent
>it checks that uid of the user making requests on it matches the one who
>started it.
>
>This doesn't help so much against a hostile root, but they could grovel
>keys out of /dev/kmem anyway (this is where hardware tokens come in).
>
>An attacker who breaks your account can still log in using the agent
>that is there, but I guess that is a little better than being able to
>take your keys away to continue their attacks at their leisure. To
>reduce this risk further you can run with key restrictions, like
>confirm-on-use ("ssh-add -c ..." - highly recommended).
>

Yes, I could still add the functionality to ssh-agent to use the 
per-process keyring which is also provided by the same kernel key 
storage...that would only allow the ssh-agent to read the keys, and it 
should also make it virtually impossible to read keys for a non-root 
attacker (won't be swapped to disc, and coredumps and ptrace would be a 
non-issue, also even if the agent segfaults, we could be sure that the 
keys are really wiped from memory).

>>I hope that cleared things up a bit...now, is the idea somewhat sane or is 
>>it whack?
>
>Well, unless the kernel gets challenge-signing capabilities, then you
>would be sacrificing security because an who breaks your account can
>read your private keys.
>
>OTOH, if the kernel gets the ability to sign challenges then we could
>treat it as a hardware token using the existing OpenSC code. Writing a
>token interface to the kernel keystore would be a really cool project
>for someone interested.
>

Yes, but some might be willing to make that sacrifice (at least until 
the kernel gets signing capabilities, if ever)...much the same way that 
you can have unencrypted secret keys on-disc currently...

>If you are frustrated by managing keys between lots of agents, then you
>can ask it to puts its SSH_AUTH_SOCK in a well-known place using (e.g.)
>"ssh-agent -a ~/.ssh/agent-sock"

Yes, I know...but the hassle is apparently enough that people are 
creating workarounds such as keychain (see 
http://www.gentoo.org/proj/en/keychain/index.xml). I think in-kernel 
keys would be a more complete solution...

Regards,
David



From mstevens at cmu.edu  Thu Jul 28 07:44:12 2005
From: mstevens at cmu.edu (Michael A Stevens)
Date: Wed, 27 Jul 2005 17:44:12 -0400 (EDT)
Subject: Linux in-kernel keys support
In-Reply-To: <Pine.BSO.4.63.0507271005370.14926@fuyu.mindrot.org>
References: <20050726210810.GB14661@hardeman.nu>
	<Pine.BSO.4.63.0507271005370.14926@fuyu.mindrot.org>
Message-ID: <Pine.GSO.4.60-041.0507271730430.639@unix2.andrew.cmu.edu>

This is an interesting patch if you want to protect against keys against 
attacks from being swapped out, or being ptraced by root. The crowd that 
this could benefit is limited as you can only ptrace ssh-agent as root and 
on most systems root can read kernel memory. I would think that most 
systems where root can not read the kernel memory root would also not be 
able to ptrace other processes. It is very easy to steal keys out of 
ssh-agent as root though, and the hashed known_hosts file makes access 
extension attacks based on this more difficult.

Mike Stevens

On Wed, 27 Jul 2005, Damien Miller wrote:

> On Tue, 26 Jul 2005, DavidH?rdeman wrote:
>
>> Hi all,
>> 
>> I recently made a patch to openssh 4.1p1 to allow it to use the in-kernel 
>> key management provided by 2.6.12 or later Linux kernels.
>
> I'm not sure I understand this: just the patch just make ssh store and 
> retrieve user authentication pubkeys from the kernel key store? It doesn't 
> appear to any kernel facilities to do the actual signing of challenges.
>
> -d
>

From djm at mindrot.org  Thu Jul 28 10:39:27 2005
From: djm at mindrot.org (Damien Miller)
Date: Thu, 28 Jul 2005 10:39:27 +1000 (EST)
Subject: New SCP? was Re: file name handling "bug" in scp?
In-Reply-To: <42E79B25.7060009@psc.edu>
References: <42E435BC.3010902@gardenali.biz>
	<20050727052045.GA16873@dementia.proulx.com>
	<e5f0f62c05072704084a92c76c@mail.gmail.com>
	<42E77788.3090404@zip.com.au> <42E79B25.7060009@psc.edu>
Message-ID: <Pine.BSO.4.63.0507281038430.13122@fuyu.mindrot.org>

On Wed, 27 Jul 2005, Chris Rapier wrote:

> I guess this leads to the question: While SCP has always in the past
> fallen back to acting like cp because that is what rcp did, is this
> still necessary? I'm not, in anyway, suggesting that scp be
> fundamentally changed though. I'm just curious is there might be a place
> for something like 'scp2' (or 'scp+' or 'thatcrazynewwackytypeofscp').
> I'm thinking of something that has similar functionality to scp but has
> enhanced functionality (parallel data streams, having a data and a
> control channel to handle multiple files more gracefully, etc etc etc).
> Any thoughts on this?

It is called sftp, but it needs more work to be a complete scp 
replacement. Starting with recursive operations.

-d



From fcusack at fcusack.com  Thu Jul 28 20:47:38 2005
From: fcusack at fcusack.com (Frank Cusack)
Date: Thu, 28 Jul 2005 03:47:38 -0700
Subject: openssh vs pam
In-Reply-To: <42BD5E66.4080500@zip.com.au>
References: <42A7862E.6080107@zip.com.au>	<20050609161940.GA29902@binky.Central.Sun.COM>
	<20050609163639.GB29902@binky.Central.Sun.COM>	<42A8DA5D.5030905@zip.com.au>
	<20050610013615.GT659@binky.Central.Sun.COM>
	<4094F650162B7F75391A073E@manatee.local>
	<42B26457.1020308@mindrot.org> <C34C72118F1117F167F8E789@manatee.local>
	<42B8AE89.3090004@zip.com.au> <E8474836FF90D3D50C8059EE@manatee.local>
	<42BD5E66.4080500@zip.com.au>
Message-ID: <FEC99712FBFF0E1C0DA1A54B@maguro.local>

On June 25, 2005 11:38:46 PM +1000 Darren Tucker <dtucker at zip.com.au> wrote:
> Frank Cusack wrote:
>  > Darren (et al.),
>  > Thanks for taking so much time here!  I wish I had more time to
>  > devote to it.
>
> That's OK.

Thanks also for being so calm in the face of some level of bitterness.
Sorry it's taken me so long to respond.  I'm amazingly busy these days.

> [about sshd's PAM interface]
> [...]
>>> It's never going to be perfect. Given the SSHv1 and v2 protocol
>>> specs and PAM as it stands I don't think it's possible.
>>
>> Disagree. It is quite possible for ssh v2 to work properly with PAM.
>> I have it working. Sun has it working.
>
> I specified SSHv1 and SSHv2, but sticking to just SSHv2, could you please explain how you do the
> following within the existing SSHv2 protocol and PAM interfaces:
>
> a) Perform the "none" auth test specified by SSHv2 via PAM without causing either unnecessary
> delays or spurious failure messages from PAM in the logs.  Currently sshd doesn't try PAM for
> "none" if PermitEmptyPasswords=no but strictly speaking that's a hack.

Can't remember exactly how I solved this, if I even did, but I definitely
did patch some code around this problem.  I think I just implemented the
hack you're talking about.  I like Nico's/Sun's approach here.

> b) Perform vanilla "password" USERAUTH_REQUEST via PAM in a way that works for the general case.
>
> Now a) you can configure around, and I imagine your response to b) will be "use kbdint, that's
> what it's for!" :-)

That's right.  passwd auth does NOT work with PAM 100% and CANNOT.  That's why kbdint
is there.  kbdint does everything passwd auth does, there's no reason to use passwd
auth.

> My point is there are parts of the spec that you can't implement perfectly via PAM, given the
> current protocol and PAM implementations. It's not that OpenSSH can't improve (I've already said
> that it can).

Sure, if you're stuck with passwd auth.  I'm not concerned about that, I'm
concerned about the things that can be fixed that aren't.

> Originally I had another thing in the list, which I now think is possible but tricky, and wanted
> to know if you implemented it and if so, how:
>
> c) Handle the case where pam_acct_mgmt() wants to interact after a public-key authentication.

I never addressed this myself.

>
>>> 6) The multiple-messages part of the PAM conversation protocol (ie
>>> allowing more than one message per call to the conversation
>>> function) is more complex than necessary and this has been a source
>>> of bugs.
>>
>> A big no here.
> [...]
>> Multiple messages are required because a) authentication exchanges
>> are not limited to single request/reply type of messages, and b)
>> clients cannot derive any semantic meaning from server-generated
>> messages.
>
> It's not that there are multiple messages in the authentication exchange, but that there's
> multiple authentication messages *per API call*, in a format that can be silently gotten wrong in
> a way that's a security problem (and, historically, has been).

huh?  Multiple messages per API call is what I'm saying is an absolute
requirement.

> Exhibit A: LinuxPAM got it wrong and nobody noticed until it was to late to fix it.  It's still
> broken to this day.
>
> (For anyone following the thread that doesn't realise: the PAM spec (XSSO, pp 89) specifies that
> the message parameter passed to the conversation function is "a pointer to an array", but
> LinuxPAM treats it as an array of pointers.  These are equivalent for the case where there's
> exactly one message but will blow up horribly for more.)

That can't be right.  The message parameter has to be dealt with in
two places, the pam module and the application.  Since Linux-PAM is
just the pam stack and modules, they don't control the applications,
applications will therefore be broken with Linux-PAM in the face of
multiple prompts.  I find it hard to believe that all applications
that have a Linux port implement both behaviors.

Ok, I've just looked at Linux-PAM-0.77 (from FC3) and of the 30
modules, 11 have a conversation interaction.  Every single one of
those does treat it incorrectly, but also every single one of
those only sends a single prompt.  So the fact that it's coded
incorrectly doesn't matter.  Most notably, pam_userdb is really
bad (getting even more wrong than mixing up arrays/pointers)
but still it only passes 1 message to conv() so it works.

I'd like to hear more if you disagree.  Although let me say
upfront that I probably won't be able to get back to this again.
Certainly all my homebrew modules work perfectly under Linux-PAM
(except when using the crud known as pam_stack).

> Exhibit B: des at freebsd, who wrote one of the PAM implementations (OpenPAM) from scratch, got it
> wrong in the FreeBSD sshd PAM code:
> http://mail-index.netbsd.org/current-users/2003/10/02/0005.html
>
> So the authors of two of the three PAM implementations I'm aware of have got it wrong at one time
> or another, in at least two cases undetected long enough to make it to released code.
>
> (and I'm not trying to pick on either des or amorgan here, but with a history of misuse of the
> interface even by folks that know it well, you have to ask if maybe the interface is at fault
> here)

Lots of interfaces are difficult.  Something as tricky as a pam
module, however, is easy to get right if you do adequate testing.
I don't see it in XSSO but in the original pam spec (OSF RFC 86.0)
there is sample code that demonstrates pointer to array.  I don't
know how you can get it wrong when you have sample code to look at.

> A separate but related issue to the fact this complex interface is supplied via a callback.  It's
> the callback that's the primary problem in sshd's case, though.  Give me a reentrant equivalent
> to the conversation function and I can live with the rest.  It could probably even fit withing
> the existing API with a few new flags.

You keep saying reentrant.  You mean asynchronous.  I agree,
such an interface can probably be wedged in.  libpam would
just have to fake the conversation function.  I'd love to work
on it if I had cycles available.

>> This is a great example of both not understanding PAM and not wanting
>> to. One, you're wrong, two, you can't imagine that the PAM interface
>> might be the way it is for a reason, rather you insist that it's
>> broken and refuse to accommodate it.
>
> You seem to be confusing understanding it with having a high opinion of it.  Do you believe that
> PAM is so fundamentally clean, elegant and beautiful that if someone understood it they could not
> fail to like it?

Yes.  I like BSDAUTH better because the authentication runs
in a separate process, but PAM is nice as well.  Part of
understanding PAM is understanding how things were when it
was developed.  Not how things are now.  TELNET was king.
ssh1 was just becoming known.  I don't think SASL was
around yet.

It's not so great for current uses, but certainly it solved
a real problem in an extensible way, and was appropriate.
And therefore elegant.

Not sure what you have against callbacks.  Because of the
stack function of pam, it's easier for app writers to supply
a callback than to deal with multiple "callinto's".

I agree, this causes problems *for SSH* but it's not such
a terrible design *in general* and especially considering
the environment in which it was developed.

[...]
>> pam_authenticate():
>>  info_request:  0: [enter password], type prompt
>>  info_response: 0: 1234
>> pam_acct_mgmt(): PAM_NEW_AUTHTOK_REQD
>> pam_chauthtok():
>>  info_request:  0: [your password has expired], type message
>>                 1: [old password], type prompt
>>                 2: [new password], type prompt
>>                 3: [verify], type prompt
>>  info_response: ...
>>
[...]
>>
>> Now, previously, in one sense I did overstate the case when I said
>> "it's easy". The issue just described is a subtle one, and is
>> probably not even understood by many of the current PAM stack
>> implementers and maintainers. Even the authors of PAM don't describe
>> this in the PAM specification, and in fact they get a few things
>> wrong! (viz, they claim kerberos and smartcard support, which isn't
>> possible strictly within the PAM framework as specified.)
>
> The authors of the standard and some of the implementations don't understand the interface?  Does
> this not indicate that the interface is too complex and thus prone to misuse?

OK, I did get ahead of myself a bit, but what I really meant
was that for application writers the complexity of the pam
stack isn't an issue.  The API that applications use isn't
difficult.

I hate to do this, but I've spent the better part of an hour on
this and it's very late here (3:40AM).  There's still a lot more
to respond to, and some of it central to our discussion, but
I just can't spend more time on this.  I'll just cherry pick
an easy last point:

>> The Sun patches are readily available.
>
> Really?  Where?  If you're referring to OpenSolaris the when I looked, ssh was one of the
> components that is not part of the release.  (Nico: any particular reason for this, and is it
> expected to change?)

oops.  Sun had released source for a bunch of packages with 'S" suffixes,
eg SUNWbashS.  I thought openssh was among those.  Anyway, it looks like
you can get it now from opensolaris.org, in the add-on crypto tarball.

Thanks again for spending so much time in an area that really
is one of the weak points of ssh anyway.  Folks should be using
pubkey auth.  Sending your password to anyone is so 1990.

-frank



From capveg at cs.umd.edu  Thu Jul 28 06:52:24 2005
From: capveg at cs.umd.edu (Rob)
Date: Wed, 27 Jul 2005 16:52:24 -0400
Subject: reference counting in ssh-agent?
Message-ID: <20050727205224.GY300@xor.cs.umd.edu>

Hi,

In a machine that I regularly use one console and remotely I have the line:

eval `ssh-agent`

In my .login, as per the ssh-agent(1) man page.

Problem: when I log out, the ssh-agent process persists which is the
correct behavior in some cases, but not in others.  This means that
periodically I have to kill off hundreds of ssh-agent processes as they
are taking up a substantial amount of my (fairly old) machine's resources.

Question: is there a trivial way of fixing this problem?  I could do some
shell scripting to kill ssh-agent in the right cases and not in others,
but that seems kludgy, and I can't imagine that I'm the only one to have
this problem.

Better question: if I were to write a patch to openssh that implemented
reference counting in ssh-agent, would that be a Useful Idea?   I was
thinking something like when a shell creates a new process, then ref=1,
if the current shell finds an existing process, send that process a signal
to increment ref, and in .logout, decrement ref and have ssh-agent exit
if ref=0.  Presumably I could find some sort of unused signal in ssh-agent
(SIGUSR1 or some such), and this seems reasonably secure.

Please let me know what people think: thanks,

- Rob
.

PS Pls make sure to CC me as I am not subscribed to the list.



From dtucker at zip.com.au  Fri Jul 29 00:46:33 2005
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 29 Jul 2005 00:46:33 +1000
Subject: reference counting in ssh-agent?
In-Reply-To: <20050727205224.GY300@xor.cs.umd.edu>
References: <20050727205224.GY300@xor.cs.umd.edu>
Message-ID: <42E8EFC9.8010300@zip.com.au>

Rob wrote:
> Problem: when I log out, the ssh-agent process persists which is the
> correct behavior in some cases, but not in others.  This means that
> periodically I have to kill off hundreds of ssh-agent processes as they
> are taking up a substantial amount of my (fairly old) machine's resources.
> 
> Question: is there a trivial way of fixing this problem?

Yes, don't do that.  :-)

> I could do some
> shell scripting to kill ssh-agent in the right cases and not in others,
> but that seems kludgy, and I can't imagine that I'm the only one to have
> this problem.

if [ ! -e ~/.ssh/myagentsock ]; then
         ssh-agent -a ~/.ssh/myagentsock >~/.ssh/myagent
fi
. ~/.ssh/myagent

or google for "ssh keychain"

> Better question: if I were to write a patch to openssh that implemented
> reference counting in ssh-agent, would that be a Useful Idea?

Probably not.  It would complicate the agent unecessarily.

-- 
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 rapier at psc.edu  Fri Jul 29 02:09:56 2005
From: rapier at psc.edu (Chris Rapier)
Date: Thu, 28 Jul 2005 12:09:56 -0400
Subject: New SCP? was Re: file name handling "bug" in scp?
In-Reply-To: <Pine.BSO.4.63.0507281038430.13122@fuyu.mindrot.org>
References: <42E435BC.3010902@gardenali.biz>	<20050727052045.GA16873@dementia.proulx.com>	<e5f0f62c05072704084a92c76c@mail.gmail.com>	<42E77788.3090404@zip.com.au>
	<42E79B25.7060009@psc.edu>
	<Pine.BSO.4.63.0507281038430.13122@fuyu.mindrot.org>
Message-ID: <42E90354.70509@psc.edu>

Its not a matter of what you call the application but what the 
application can do. SFTP is still lacking critial features that would 
enhance its overall usefullness. On a functional level the main 
difference between SFTP and SCP seems to be the UI. For example, as far 
as I can tell (using xplot to look at the time sequence graphs) it still 
enters slow start for every file that is transfered with an mget. Thats 
a huge performance hit. I can't but help think that there is a viable 
way around that.

What I was hoping to do was to start a discussion on what sort of 
features people would like to see. I'm not, in anyway, saying that SFTP 
or SCP or any of the work OpenSSH has done is less than stellar. I'm 
only trying to think about where it can go from here.

Damien Miller wrote:
> On Wed, 27 Jul 2005, Chris Rapier wrote:
> 
> 
>>I guess this leads to the question: While SCP has always in the past
>>fallen back to acting like cp because that is what rcp did, is this
>>still necessary? I'm not, in anyway, suggesting that scp be
>>fundamentally changed though. I'm just curious is there might be a place
>>for something like 'scp2' (or 'scp+' or 'thatcrazynewwackytypeofscp').
>>I'm thinking of something that has similar functionality to scp but has
>>enhanced functionality (parallel data streams, having a data and a
>>control channel to handle multiple files more gracefully, etc etc etc).
>>Any thoughts on this?
> 
> 
> It is called sftp, but it needs more work to be a complete scp 
> replacement. Starting with recursive operations.
> 
> -d
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev



From jmknoble at pobox.com  Fri Jul 29 02:51:50 2005
From: jmknoble at pobox.com (Jim Knoble)
Date: Thu, 28 Jul 2005 12:51:50 -0400
Subject: reference counting in ssh-agent?
In-Reply-To: <20050727205224.GY300@xor.cs.umd.edu>
References: <20050727205224.GY300@xor.cs.umd.edu>
Message-ID: <20050728165149.GG14847@crawfish.ais.com>

Circa 2005-07-27 dixit Rob:

: In a machine that I regularly use one console and remotely I have the line:
: 
: eval `ssh-agent`
: 
: In my .login, as per the ssh-agent(1) man page.
: 
: Problem: when I log out, the ssh-agent process persists which is the
: correct behavior in some cases, but not in others.  This means that
: periodically I have to kill off hundreds of ssh-agent processes as they
: are taking up a substantial amount of my (fairly old) machine's resources.
: 
: Question: is there a trivial way of fixing this problem?  I could do some
: shell scripting to kill ssh-agent in the right cases and not in others,
: but that seems kludgy, and I can't imagine that I'm the only one to have
: this problem.

If you want the agent to be ephemeral (i.e., to last only for your login
session), then you should kill the agent in your logout script
(~/.logout for csh, ~/.bash_logout for bash, a kludge involving 'trap
... 0' for pdksh).  I do this in a fashion similar to the following:

    ~/.bash_profile:

        if [ -f "${HOME}/.ssh-agent" ]; then
            SSH_AGENT=`cat "${HOME}/.ssh-agent"`
        fi
        SSH_AGENT="${SSH_AGENT:-/usr/bin/ssh-agent}"
        if [ -z "${SSH_AUTH_SOCK}" ] && \
           [ -f "${HOME}/.use-ssh-agent" ] && \
           [ -x "${SSH_AGENT}" ]
        then
            eval `${SSH_AGENT}`
        fi

    ~/.bash_logout:

        if [ -f "${HOME}/.ssh-agent" ]; then
            SSH_AGENT=`cat "${HOME}/.ssh-agent"`
        fi
        SSH_AGENT="${SSH_AGENT:-/usr/bin/ssh-agent}"
        if [ -n "${SSH_AGENT_PID}" ] && \
           [ -x "${SSH_AGENT}" ]
        then
            eval `${SSH_AGENT} -k`
        fi

It's a little complex, but basically:

    - ~/.ssh-agent optionally contains the path to the ssh-agent program.

    - ~/.use-ssh-agent, if present, says we want ssh-agent to run
      automatically in each login session.

    - ssh-agent is only run if it's not already running in a parent of
      the current session (we check the SSH_AUTH_SOCK environment
      variable for that).

    - if ssh-agent is disabled by removing execute permission, then we
      don't try to use it.

For csh, it would look a little different; i don't know csh very well,
so someone else would need to figure that out.

For ksh, the above should work virtually unchanged; the only difference
may be in how quotes are interpreted inside backquotes (`), and that's
not generally a problem unless you have, for example, a space character
in the path to your home directory.  To make pdksh run a script (such as
~/.ksh_logout) on logout, put the following in your ~/.profile:

    ksh_logout() {
        if [ -s "${HOME}/.ksh_logout" ]; then
            . "${HOME}/.ksh_logout"
        fi
    }
    case "$-" in
        *i*)
            # Interactive shell
            if [ -n "${KSH_VERSION}" ]; then
                trap ksh_logout 0
            fi
        ;;
    esac

Good luck.

-- 
jim knoble  |  jmknoble at pobox.com  |  http://www.pobox.com/~jmknoble/
(GnuPG fingerprint: 809F:09B9:9686:D035:4AB0::9455:124B:0A62:DD6A:76D6)
 .....................................................................
 :"The methods now being used to merchandise the political candidate :
 : as though he were a deodorant positively guarantee the electorate :
 : against ever hearing the truth about anything."   --Aldous Huxley :
 :...................................................................:



From thirdtype+dev2 at sent.com  Fri Jul 29 05:29:46 2005
From: thirdtype+dev2 at sent.com (thirdtype+dev2 at sent.com)
Date: Thu, 28 Jul 2005 15:29:46 -0400
Subject: greater than 8 character passwords on Unixware (IA database support)
Message-ID: <1122578986.6580.239460965@webmail.messagingengine.com>

I made some quick changes to support the IA security thing in Uniware
7.1.1. I wish I understood all of this well enough to make a proper
patch to include new defines and what not. I tried and made a mess.
Hopefully I can get a better grasp this weekend. The only files I
changed were xcrypt.c and Makefile.

Makefile needed -lcrypt and -liaf added to LIBS=. It had -lcrypto but
needed -lcrypt for bigcrypt()

xcrypt.c needed:
- #include <ia.h>
- xcrypt() needed to call bigcrypt()
- shadow_pw() needed this, although it didn't really belong there:
uinfo_t uinfo;
ia_openinfo(pw->pw_name, &uinfo);
ia_get_logpwd(uinfo, &pw_password);
ia_closeinfo(uinfo);



From rapier at psc.edu  Fri Jul 29 07:01:12 2005
From: rapier at psc.edu (Chris Rapier)
Date: Thu, 28 Jul 2005 17:01:12 -0400
Subject: People using the HPN patch...
Message-ID: <42E94798.1010403@psc.edu>

If anyone is using the HPN patch on a high performance link I was 
wondering if you could take a moment to answer a quick question

Are you seeing vastly different performance between scp throughput and 
sftp throughput? On my test network (pittsburgh to chicago) I'm getting 
26MB/s with scp (arcfour) and only 6.4MB/s with sftp (arcfour). We just 
started looking into this but it woudl be nice to know that its not just 
some weirdness associated with our network.

Thanks.

Chris



From djm at mindrot.org  Fri Jul 29 08:08:32 2005
From: djm at mindrot.org (Damien Miller)
Date: Fri, 29 Jul 2005 08:08:32 +1000
Subject: People using the HPN patch...
In-Reply-To: <42E94798.1010403@psc.edu>
References: <42E94798.1010403@psc.edu>
Message-ID: <42E95760.3060502@mindrot.org>

Chris Rapier wrote:
> If anyone is using the HPN patch on a high performance link I was 
> wondering if you could take a moment to answer a quick question
> 
> Are you seeing vastly different performance between scp throughput and 
> sftp throughput? On my test network (pittsburgh to chicago) I'm getting 
> 26MB/s with scp (arcfour) and only 6.4MB/s with sftp (arcfour). We just 
> started looking into this but it woudl be nice to know that its not just 
> some weirdness associated with our network.

Try playing with sftp's -B and -R options, you might be able to get
better performance on LFPs.

-d



From tim at multitalents.net  Fri Jul 29 11:52:47 2005
From: tim at multitalents.net (Tim Rice)
Date: Thu, 28 Jul 2005 18:52:47 -0700 (PDT)
Subject: greater than 8 character passwords on Unixware (IA database
	support)
In-Reply-To: <1122578986.6580.239460965@webmail.messagingengine.com>
References: <1122578986.6580.239460965@webmail.messagingengine.com>
Message-ID: <Pine.UW2.4.63.0507281848300.10129@server01.int.multitalents.net>

On Thu, 28 Jul 2005, thirdtype+dev2 at sent.com wrote:

> I made some quick changes to support the IA security thing in Uniware
> 7.1.1. I wish I understood all of this well enough to make a proper
> patch to include new defines and what not. I tried and made a mess.

Hold tight for a little while. 
I've got a patch from Ahsan Rashid that may do what you need.
Give us some time to clean it up and test it.

> Hopefully I can get a better grasp this weekend. The only files I
> changed were xcrypt.c and Makefile.
> 
> Makefile needed -lcrypt and -liaf added to LIBS=. It had -lcrypto but
> needed -lcrypt for bigcrypt()
> 
> xcrypt.c needed:
> - #include <ia.h>
> - xcrypt() needed to call bigcrypt()
> - shadow_pw() needed this, although it didn't really belong there:
> uinfo_t uinfo;
> ia_openinfo(pw->pw_name, &uinfo);
> ia_get_logpwd(uinfo, &pw_password);
> ia_closeinfo(uinfo);

-- 
Tim Rice				Multitalents	(707) 887-1469
tim at multitalents.net




From bob at proulx.com  Fri Jul 29 15:08:38 2005
From: bob at proulx.com (Bob Proulx)
Date: Thu, 28 Jul 2005 23:08:38 -0600
Subject: reference counting in ssh-agent?
In-Reply-To: <20050727205224.GY300@xor.cs.umd.edu>
References: <20050727205224.GY300@xor.cs.umd.edu>
Message-ID: <20050729050838.GA16906@dementia.proulx.com>

Rob wrote:
> In a machine that I regularly use one console and remotely I have the line:
> 
> eval `ssh-agent`
> 
> In my .login, as per the ssh-agent(1) man page.

Ew, yuck.  Remember that is the second entry in the man page.  The
first entry is the one you want.  At least it is the one I want.

> Problem: when I log out, the ssh-agent process persists which is the
> correct behavior in some cases, but not in others.  This means that
> periodically I have to kill off hundreds of ssh-agent processes as they
> are taking up a substantial amount of my (fairly old) machine's resources.

Yep.

> Question: is there a trivial way of fixing this problem?

Doctor, doctor, it hurts when I do this.  So don't do that.  :-)

The first usage synopsis in the man page is:

     ssh-agent [-a bind_address] [-c | -s] [-t life] [-d] [command [args ...]]

     ...
     If a commandline is given, this is executed as a subprocess of the agent.
     When the command dies, so does the agent.

That is the usage I prefer.  Since I am running X11 most of the time
the distro I am using automatically starts the ssh-agent up as part of
the X session.  When I log out, the agent exits.

  exec ssh-agent ~/.xsession

For me on my Debian system the above is automatic.  But if it is not
on your system then I would start it up with my window manager as the
command.

In a ~/.xsession file.

  #!/bin/bash --login
  exec ssh-agent fvwm # or startkde or gnome-session or whatever

Since you said ~/.login:

  #!/bin/csh -l
  exec ssh-agent fvwm # or startkde or gnome-session or whatever

But you mentioned a console.  When I need this manually from a random
command line shell window I usually run the following commands.

  exec ssh-agent $SHELL
  ssh-add

You can automate this with the following as the very last thing in
your ~/.profile (or ~/.bash_profile) so that an agent is always
available when you log into a system.  Remember that the current shell
is replaced and overlayed with a new one when the 'exec' command is
run.  No commands after that in the script will be run because the
shell interpreting the script no longer exists.

  ssh-add -l >/dev/null 2>&1
  if [ $? -eq 2 ] ; then
    exec ssh-agent $SHELL
  fi

When I log out, the agent exits.  I never have to worry about reaping
in orphaned ssh-agents.

You said ~/.login so:

  ssh-add -l >& /dev/null
  if ( $status ) then
    exec ssh-agent $SHELL
  endif

Bob



From rapier at psc.edu  Fri Jul 29 23:50:36 2005
From: rapier at psc.edu (Chris Rapier)
Date: Fri, 29 Jul 2005 09:50:36 -0400
Subject: People using the HPN patch...
In-Reply-To: <42E95760.3060502@mindrot.org>
References: <42E94798.1010403@psc.edu> <42E95760.3060502@mindrot.org>
Message-ID: <42EA342C.20105@psc.edu>

Damien Miller wrote:

> Chris Rapier wrote:
> 
>>If anyone is using the HPN patch on a high performance link I was 
>>wondering if you could take a moment to answer a quick question
>>
>>Are you seeing vastly different performance between scp throughput and 
>>sftp throughput? On my test network (pittsburgh to chicago) I'm getting 
>>26MB/s with scp (arcfour) and only 6.4MB/s with sftp (arcfour). We just 
>>started looking into this but it woudl be nice to know that its not just 
>>some weirdness associated with our network.
> 
> 
> Try playing with sftp's -B and -R options, you might be able to get
> better performance on LFPs.

Thanks for the clue. Increasing the number of requests seemed to do the trick. 
Changing the buffer size also had an impact but not as much (100% increase as 
opposed to 400% increase by setting R to 64). Now the big question is, what is 
a request in this context? Are you using them like ACKs to do congestion control?



From djm at mindrot.org  Sat Jul 30 11:40:42 2005
From: djm at mindrot.org (Damien Miller)
Date: Sat, 30 Jul 2005 11:40:42 +1000
Subject: People using the HPN patch...
In-Reply-To: <42EA342C.20105@psc.edu>
References: <42E94798.1010403@psc.edu> <42E95760.3060502@mindrot.org>
	<42EA342C.20105@psc.edu>
Message-ID: <42EADA9A.6050603@mindrot.org>

Chris Rapier wrote:
> Thanks for the clue. Increasing the number of requests seemed to do the trick. 
> Changing the buffer size also had an impact but not as much (100% increase as 
> opposed to 400% increase by setting R to 64). Now the big question is, what is 
> a request in this context? Are you using them like ACKs to do congestion control?

When uploading or downloading a file, the client sends num_requests (-R)
of buffer_size (-B) bytes before waiting for acknowledgement so as not
to stall. In this context, a request is a draft-ietf-secsh-filexfer-03
command to read or write a range of bytes to/from a file.

The default num_requests is 16, which is big enough for smaller BDP
pipes but obviously not sufficient for larger ones. It could probably be
tuned higher without much cost.

As you have already observed, sftp only maintains a window of requests
when actually uploading or downloading a file - it doesn't do when
fetching directory contents or for successive transfers. Adding it to
sftp-client.c:do_lsreaddir() would be pretty easy, but doing it right
for multiple transfers would be a bit more tricky.

-d