wont compile on linux and freebsd

[GoogleCodeExporter]

What steps will reproduce the problem?
1. check out of repository using the svn command copied from
http://code.google.com/p/ppp-pam/source
2. cd into the dir
3. type make

What is the expected output? What do you see instead?
On linux I got this error:
ppp/ppp.o: In function `generateRandomSequenceKey':
ppp.c:(.text+0xdd6): undefined reference to `uuid_generate_time'
ppp.c:(.text+0xe03): undefined reference to `uuid_generate_random'
collect2: ld returned 1 exit status
make: *** [build/pppauth] Error 1

on freebsd I got this error:
ppp/ppp.c: In function 'generateRandomSequenceKey':
ppp/ppp.c:401: error: 'uuid_t' undeclared (first use in this function)
ppp/ppp.c:401: error: (Each undeclared identifier is reported only once
ppp/ppp.c:401: error: for each function it appears in.)
ppp/ppp.c:401: error: expected ';' before 'uuid'
ppp/ppp.c:405: warning: implicit declaration of function 'uuid_generate_time'
ppp/ppp.c:405: error: 'uuid' undeclared (first use in this function)
ppp/ppp.c:410: warning: implicit declaration of function 'uuid_generate_random'
*** Error code 1

What version of the product are you using? On what operating system?
I ran it on 2 linux (Gentoo) boxes (both same error)
1st computer 
-Linux *** 2.6.18.1 #2 SMP PREEMPT Mon Oct 30 09:56:39 CST 2006 i686
Intel(R) Pentium(R) 4 CPU 3.40GHz GenuineIntel GNU/Linux
-gcc version 4.2.0 (Gentoo 4.2.0 p1.4)
2nd computer:
-Linux **** 2.6.21 #3 SMP PREEMPT Fri Apr 27 06:24:46 CDT 2007 x86_64
Intel(R) Pentium(R) 4 CPU 3.40GHz GenuineIntel GNU/Linux
-gcc version 4.1.2 (Gentoo 4.1.2)

and the freebsd box:
FreeBSD lilith 7.0-CURRENT-200706 FreeBSD 7.0-CURRENT-200706 #0: Thu Jun  7
21:38:42 UTC 2007    
root@stiles.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64
gcc version 4.2.0 20070514 [FreeBSD]

Please provide any additional information below.
Any one else having the same problem?
Does anyone have any ideas what the problem could be?
I did not see a readme anywhere, are there instructions for
compiling/installing?

Original issue reported on code.google.com by clarke.h...@gmail.com on 26 Oct 2007 at 9:52

[GoogleCodeExporter]

It looks like the uuid stuff for generating the random key is not as portable 
as I
had hoped. What do you get when you type 'man uuid_generate' at the shell 
prompt on
your various machines?

Original comment by tomf...@gmail.com on 26 Oct 2007 at 10:20

• Changed state: Accepted

[GoogleCodeExporter]

I've tried compiling it under Ubuntu Gutsy (64 bit) and can confirm the above
mentioned problems. I usually do not program in C, but these are the answers I 
found
so far:

The following development packages have to be added:
- uuid-dev
- libpam0g-dev 

The pam include files are then installed at <security/...> not <pam/...>
(I modified the source)

pam_mod_misc.h does not exist.
(I commented that out)

Linking to /lib/libuuid.so.1 will provide the missing uuid_generate_* symbols.
(I added a PPPAUTH_OBJS and PAM_OBJS in the Makefile)

The gcc 4.1.3 version on my system does not recognize the command line options
-no-cpp-precomp nor -bundle

My current problems is that the "main" function is missing. Given the fact, 
that we
want to compile a plug-in, this is understandable. I presume this is what the
"-bundle" option is about.

Perhaps someone with more knowledge about gcc can take it from here.

Original comment by Michael.Strecke on 27 Oct 2007 at 12:21

[GoogleCodeExporter]

I've managed to get the code to compile under linux (debian etch).  This is 
just a 
quick hack, these changes obviously can't be used as is because it'll break the 
Mac 
version.  But it should be easy enough to add in ifdefs or whatever to get the 
code 
to build on both OSs.

Haven't tested whether the PAM module actually works yet either.  Patch 
attached.

Original comment by gavin.ki...@gmail.com on 27 Oct 2007 at 5:43

Attachments:

• linux_build.patch

[GoogleCodeExporter]

Using gavin.kinsey's patch plus the additional PPPAUTH_OBJS and PAM_OBJS lines
mentioned by Michael.Strecke, I was able to compile this on my gentoo box, 
however,
the install path for pam_ppp.so is wrong. It appears that this should be 
installed to
/lib/security/pam_ppp.so .

After correcting install paths and following the remainder of the instructions, 
I am
never prompted for a passcode, so there is still a little hacking left to do.

Modified patch attached.

Original comment by justaran...@gmail.com on 27 Oct 2007 at 8:23

Attachments:

• gentoo.patch

[GoogleCodeExporter]

Oops, attached wrong patch, they're functionally equivalent, but this one is 
less
different from gavin.kinsey's

Original comment by justaran...@gmail.com on 27 Oct 2007 at 8:26

Attachments:

• linux_build.patch

[GoogleCodeExporter]

okay, I've tracked down my problem: readKeyFile() can't find the key dir

changing the "/Users/" to "/home" in setUser() in ppp/keyfiles.c fixes it. :D

Original comment by justaran...@gmail.com on 29 Oct 2007 at 1:10

[GoogleCodeExporter]

The next bit that has to be changed for Linux:

ppp/keyfiles.c in setUser: 
        strncpy(userhome, "/Users/", 7);
        strncat(userhome, user, 120);
->
        strncpy(userhome, "/home/", 6);
        strncat(userhome, user, 121);

Original comment by Michael.Strecke on 29 Oct 2007 at 1:21

[GoogleCodeExporter]

Okay, this should be a full patch to make this build and work on linux now.

This is gavin.kinsey's patch, plus a fix to the help in ppp/cmdline.c(there was 
a \n
missing on the line before --passphrase), the install path change and the user 
path
change, which appears to be the minimal set of changes to compile and work.

Enjoy :-)

Original comment by justaran...@gmail.com on 29 Oct 2007 at 1:43

Attachments:

• linux_patch.patch

[GoogleCodeExporter]

I've now tested this latest patch on my Debian box too and it works great 
there. I
had to adjust the sshd_config a bit to make it use PAM properly, but after doing
that, I was able to log in perfectly :D.

I would like to note that key based logon seems to bypass any PAM modules 
entirely,
but that could just be me not finding some magic setting.

Original comment by justaran...@gmail.com on 29 Oct 2007 at 4:25

[GoogleCodeExporter]

Hey thanks for all the help guys!

I converted the svn code to use autoconf/automake and included your patches. 
Instructions are on the Wiki tab under Building.  I am now able to get pppauth 
to
work fine on ubuntu 6.06.1, but the PAM module fails when loggin in.  I builds
successfully, but /var/log/auth.log indicates the following errors and I get the
access denied message on the console.

PAM unable to dlopen(/lib/security/pam_ppp.so)
PAM [dlerror: /lib/security/pam_ppp.so: undefined symbol: mp_toradix]
PAM adding faulty module: /lib/security/pam_ppp.so

Original comment by tomf...@gmail.com on 29 Oct 2007 at 4:52

[GoogleCodeExporter]

Tom, check your sshd_config, I had to set ChallengeResponseAuthentication to 
yes on
my Debian box for it to work (the prompt for you static password will be 
something
like "user@host's password:" if it's set to no and just "Password:" if it's 
yes). I
believe my Gentoo box was already set this way, but I may have done that at some
point in the past. Also, obviously, UsePAM must be yes, but that was already 
set on
both of my boxen.

Original comment by justaran...@gmail.com on 29 Oct 2007 at 5:04

[GoogleCodeExporter]

Hmm, actually, just read you message again and realized that I had only read the
first half of it originally... So, comment 11's contents might need to be in 
the Wiki
instruction page, but it won't help your specific problem.

Original comment by justaran...@gmail.com on 29 Oct 2007 at 5:20

[GoogleCodeExporter]

Ok, I set ChallengeResponseAuthentication to yes.  UsePAM was already yes as you
pointed out, but it still fails with the same errors in /var/log/auth.log

I suspect that my .so file is not being built correctly, but I'm not sure why.

I even tried reverting to revision 18 of the svn code and applying your patch 
to it.
 Same problem, so it's something with my configuration that's causing the problem. 
It's a pretty bare-bones ubuntu 6.06.1 installation.  The only packages I added 
to
the basic install are:

subversion
make
gcc
g++
libc6-dev
uuid-dev
libpam0g-dev
openssh-server

and of course, I let it do a system update.

Original comment by tomf...@gmail.com on 29 Oct 2007 at 5:43

[GoogleCodeExporter]

I'd just like to confirm tomfors' report. I am getting the same error in 
auth.log,
but my sshd just skips the unloadable module and still lets me login. This is 
on a
decidedly non-standard and non-barebones Ubuntu 7.10 box.

Original comment by SohumB on 29 Oct 2007 at 6:47

[GoogleCodeExporter]

It seems that the entire mpi library hasn't been linked to pam_ppp.so

$ ldd -r pam_ppp.so
undefined symbol: mp_toradix    (./pam_ppp.so)
undefined symbol: mp_init       (./pam_ppp.so)
undefined symbol: mp_read_radix (./pam_ppp.so)
undefined symbol: mp_clear      (./pam_ppp.so)
[...]
undefined symbol: mp_radix_size (./pam_ppp.so)
undefined symbol: mp_sub        (./pam_ppp.so)
undefined symbol: mp_div_d      (./pam_ppp.so)
        linux-gate.so.1 =>  (0xffffe000)
        libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7df4000)
        libpam.so.0 => /lib/libpam.so.0 (0xb7dec000)
        libuuid.so.1 => /lib/libuuid.so.1 (0xb7de9000)
        /lib/ld-linux.so.2 (0x80000000)
        libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7de5000)

On the other hand, "ldd -r pppauth" does not report any undefined symbols, and 
seems
to work fine.

Original comment by Michael.Strecke on 29 Oct 2007 at 12:43

[GoogleCodeExporter]

I just tested the new stuff (r24 and the new instructions) on my gentoo box and 
I'm
seeing all the same errors as you guys, but r18+patch compiles just fine and 
says
this about itself:
$ ldd -r pam_ppp.so
linux-gate.so.1 =>  (0xffffe000)
libc.so.6 => /lib/libc.so.6 (0xb7ea8000)
libpam.so.0 => /lib/libpam.so.0 (0xb7e9d000)
libuuid.so.1 => /lib/libuuid.so.1 (0xb7e9a000)
/lib/ld-linux.so.2 (0x80000000)
libdl.so.2 => /lib/libdl.so.2 (0xb7e96000)

Original comment by justaran...@gmail.com on 29 Oct 2007 at 3:43

[GoogleCodeExporter]

It's interesting that r18+patch worked and r24 didn't.  I thought I tried 
r18+patch
and it failed for me, but it's possible I did something wrong.  I'll try that 
again
tonight.

The mpi library *should* be linked statically.  I tried to have all the code 
here
(ppp, mpi, rijndael, sha2) linked statically so we don't have to go around 
installing
libraries on people's systems.  So, running 'nm pam_ppp.so | grep mp_toradix' 
should
give you a line with a T in it, not a U.

On a broken system, try running 'nm libmpi.a | grep mp_toradix' and see if you 
get a
U or a T.

It sounds like it's just a linking issue between the different systems.

Original comment by tomf...@gmail.com on 29 Oct 2007 at 5:32

[GoogleCodeExporter]

Would someone with a working linux system please do the following?

make
touch libmpi.a
make

copy and paste the commands echoed after the last make here.

Thanks!

Original comment by tomf...@gmail.com on 29 Oct 2007 at 5:35

[GoogleCodeExporter]

/bin/bash ./libtool --mode=link gcc  -g -O2   -o pppauth  pppauth-pppauth.o
pppauth-cmdline.o pppauth-print.o pppauth-http.o libmpi.a libppp.a -luuid 
gcc -g -O2 -o pppauth pppauth-pppauth.o pppauth-cmdline.o pppauth-print.o
pppauth-http.o  libmpi.a libppp.a -luuid
/bin/bash ./libtool --mode=link gcc  -g -O2   -o pam_ppp.so -shared -lc -lpam 
-luuid
pam_ppp_so-pam_ppp.o libmpi.a libppp.a 
gcc -g -O2 -o pam_ppp.so -shared pam_ppp_so-pam_ppp.o  -lc -lpam -luuid 
libmpi.a libppp.a

Original comment by Michael.Strecke on 29 Oct 2007 at 7:07

[GoogleCodeExporter]

nm libmpi.a

on an Ubuntu Feisty system (-r 24)

Original comment by Michael.Strecke on 29 Oct 2007 at 7:13

Attachments:

• nmdump.txt

[GoogleCodeExporter]

It appears that I'm seeing two problems.  On some linux systems, the mpi 
routines are
in libmpi.a but not in pam_ppp.so.  On other linux systems, the mpi routines 
are in
neither libmpi.a nor pam_ppp.so.

I think I need to work on my Makefile.am to get consistent linking.

Just to confirm Michael, your Ubuntu Feisty system -r 24 is not working right?

Thanks.

Original comment by tomf...@gmail.com on 29 Oct 2007 at 7:27

[GoogleCodeExporter]

Can someone on a broken linux system issue the following commands please?

make
gcc -g -O2 -o pam_ppp.so -shared pam_ppp_so*.o -lc -lpam -luuid libppp_a* 
libmpi_a*
sudo make install

Then test it to see if the authentication is now working.

Original comment by tomf...@gmail.com on 29 Oct 2007 at 7:34

[GoogleCodeExporter]

-> 21:  -r24 does not run correctly (missing symbols)
-> 22: yeah! :-)

Original comment by Michael.Strecke on 29 Oct 2007 at 7:42

[GoogleCodeExporter]

On a broken system:

% nm pam_ppp.so | grep mp_toradix
         U mp_toradix
% nm libmpi.a | grep mp_toradix 
000030d0 T mp_toradix

Original comment by SohumB on 29 Oct 2007 at 7:54

[GoogleCodeExporter]

Okay, I think -r29 should fix the linking problems under linux.  Thanks for all 
the
help guys.  I'll hold off on closing this issue until I've heard a few success
stories here.

--Tom

Original comment by tomf...@gmail.com on 29 Oct 2007 at 7:56

[GoogleCodeExporter]

After running 22s fix, both nm's show a T, and it installs properly, and there 
are no
more errors in auth.log. I am not prompted for my passcode when I ssh in, 
however,
but that is probably some configuration idiocy I have done.

Original comment by SohumB on 29 Oct 2007 at 8:00

[GoogleCodeExporter]

SohumB, check sshd_config (see comment 11). I would assume you already did 
this, but
I was chasing that one for about a half hour yesterday, so it's possible 
someone else
is doing the same :-).

Also, I'm testing r29 now, results soon.

Original comment by justaran...@gmail.com on 29 Oct 2007 at 8:05

[GoogleCodeExporter]

Hm. It does work (and wonderfully) if I set PubKeyAuthentication to No, so you 
can
count this as a confirmation. But there has to be a way to use both...

Original comment by SohumB on 29 Oct 2007 at 8:16

[GoogleCodeExporter]

r29 works great on my gentoo, but debian doesn't seem to like mpi/mpi.h very 
much.
lots of these:
./../mpi/mpi.h:71: error: expected specifier-qualifier-list before 'mp_sign'
./../mpi/mpi.h:86: error: expected '=', ',', ';', 'asm' or '__attribute__' 
before
'mp_init'
./../mpi/mpi.h:87: error: expected '=', ',', ';', 'asm' or '__attribute__' 
before
'mp_init_array'

SohumB: yeah, it would be nice to be able to use a key and a passcode together, 
but I
didn't see any magic to make that happen. If you want it to prompt you for a 
passcode
in cases where you're doing password auth (if you allow that), you can set
ChallengeResponseAuthentication to yes and turn PubKeyAuthentication back on. 
Then,
if you use your key, it will log in immediately, but if you don't have your key
handy, you need a password and passcode to get in.

Original comment by justaran...@gmail.com on 29 Oct 2007 at 8:30

[GoogleCodeExporter]

Some problem with r29 as mentioned in comment #29 on an Ubuntu Feisty system.

Original comment by Michael.Strecke on 29 Oct 2007 at 8:34

[GoogleCodeExporter]

I just fixed an error in the Makefile.  I don't think it will fix the problem, 
but it
just might.  Give -r30 a try and see if it helps.  If not, let me know if the
following helps:

1. Confirm that 'make' creates mpi-types.h
2. If yes, run:
   ln -s mpi-types.h ../mpi/mpi-types.h
   make

Original comment by tomf...@gmail.com on 29 Oct 2007 at 8:52

[GoogleCodeExporter]

~/ppp-pam/mpi$ ./types.pl >mpi-types.h
fixed it on my Debian system with r29

r30 works out of the box, though there is no mpi-types.h after it's done.

Original comment by justaran...@gmail.com on 29 Oct 2007 at 9:01

[GoogleCodeExporter]

That's odd.  It should have created mpi-types.h in the build folder.  I'll take 
a
look at it when I get home and see if I can get it working properly.  I'm glad 
to
hear it's just mpi-types.h causing the problems and not something more major.

Original comment by tomf...@gmail.com on 29 Oct 2007 at 9:10

[GoogleCodeExporter]

oh, yes, it does exist in build, I was looking in mpi/ because that's where i 
had
created it by hand (obviously, i rm'ed that one before testing r30)

Original comment by justaran...@gmail.com on 29 Oct 2007 at 9:12

[GoogleCodeExporter]

Ubuntu Feisty, r30:
- does not run out of the box (error messages from #29)
- no mpi-types to be found in the entire tree
- creating the file (see #32 by justarandomgeek) helps

It then compiles and works ok.

Original comment by Michael.Strecke on 29 Oct 2007 at 11:20

[GoogleCodeExporter]

I found a missing dependency that I just added to -r31.  I think this will 
solve the
missing mpi-types.h problem.  At least it worked for me on ubuntu 7.10 and 
6.06.1 as
well as Debian 4.0 r1.  Unfortunately, on debian, the authentication fails for 
me. 
Not sure why yet.

Original comment by tomf...@gmail.com on 30 Oct 2007 at 2:09

[GoogleCodeExporter]

Works now like a charm on this Ubuntu 7.04 (Feisty Fawn) system.

Thanks

Original comment by Michael.Strecke on 30 Oct 2007 at 8:23

[GoogleCodeExporter]

Anyone seen this before? I am on suse 64bit

./../ppp/pam_ppp.c:49:30: error: pam/pam_modules.h: No such file or directory
./../ppp/pam_ppp.c:50:31: error: pam/pam_mod_misc.h: No such file or directory
./../ppp/pam_ppp.c:51:30: error: pam/_pam_macros.h: No such file or directory
./../ppp/pam_ppp.c:59: error: expected â=â, â,â, â;â, âasmâ or 
â__attribute__â 
before âintâ
./../ppp/pam_ppp.c:112: error: expected â=â, â,â, â;â, âasmâ or 
â__attribute__â 
before âintâ
make: *** [pam_ppp_so-pam_ppp.o] Error 1

Original comment by codeb...@gmail.com on 31 Oct 2007 at 11:38

[GoogleCodeExporter]

I figured out the problem...I thought these packages where installed 
- uuid-dev
- libpam0g-dev
but as it turns out they are named slightly different on SuSe
-pam-devel-0.99.8.1-15.i586.rpm
-libuuid-devel-1.40.2-20.i586.rpm

Also since I am on 64bit I put pam_ppp.so in /lib64/security instead.

I installed those and now ppp-pam is working great! Count 64bit SuSe in as 
supported.

Original comment by codeb...@gmail.com on 1 Nov 2007 at 1:17

[GoogleCodeExporter]

Thanks codeblur.  I'll update the wiki with the info and see if I can't detect 
64-bit
linux in the configure step and change the install path to /lib64/security.

Original comment by tomf...@gmail.com on 1 Nov 2007 at 1:37

[GoogleCodeExporter]

I still need to test this on freebsd.  I've tried to install freebsd in a 
virtual
machine on my mac an so far have had no luck.

Original comment by tomf...@gmail.com on 1 Nov 2007 at 1:38

• Changed state: Started

[GoogleCodeExporter]

I just noticed that when I put in the command below it just hangs there and 
doesn't 
seem to do anything. 
pppauth --html --next 3

pppauth --text --next 3 works fine

Original comment by codeb...@gmail.com on 1 Nov 2007 at 1:43

[GoogleCodeExporter]

I should disable the --html option under linux until I can figure out how to 
make it
work.  On mac, it starts a bare-bones http server on some tcp port.  It then 
calls
the open command with the url http://localhost:portnum which gets an html 
version of
the passcodes just like GRC's layout.  As soon as the server returns the 
passcodes,
it dies so another connection to that port fails.

I should probably add some random "salt" in the url in addition to the weakly 
obscure
port number since, in theory, someone else on the machine could get the http
connection to that port before you.

Anyway, on the linux side, I haven't tested the http server to confirm that it 
works,
and I don't know a easy, reliable way to launch a web browser and open
localhost:portnum.  Yet! :-)

For now, you'll have to use the --text printing option or, if you pass the 
--verbose
flag, it will display your sequence key as a hex string which you can then 
cut/paste
into grc.com/ppp to get nicely formatted passcards.

I really need to write-up some documentation on pppauth :-)

Original comment by tomf...@gmail.com on 1 Nov 2007 at 2:33

[GoogleCodeExporter]

Tom, as a temporary fix for the --html, why not make it echo the html to stdout 
on
linux. Then we can simply run pppauth --html --next 3>temp.html, view that in 
our
browser of choice and then delete the file!

Original comment by justaran...@gmail.com on 3 Nov 2007 at 4:03

[GoogleCodeExporter]

Okay, two patches here:
one, cmdline.patch, fixes a few minor things in the usage (another missing \n 
and two
tweaks to allow --passphrase --next and --card to be used together as long as 
all
three are used, for testing purposes)
the other, more relevant one, http.patch, is the beginning of a fix/workaround 
for
--html on linux. it will print the url to the passcodes on stdout when run for 
you to
copy/paste into your browser of choice. however, I haven't got it to do 
anything but
refuse the connection so far, so it is of limited use

Original comment by justaran...@gmail.com on 3 Nov 2007 at 8:14

Attachments:

• cmdline.patch
• http.patch

[GoogleCodeExporter]

justarandomgeek,

Thanks for the patches!  I've implemented them and also got --http working under
linux in -r58

I'm going to add some obfuscation to the localhost URL now for extra security.

--Tom

Original comment by tomf...@gmail.com on 4 Nov 2007 at 3:32

[GoogleCodeExporter]

I'm going to close this issue since the comment thread has kind of wandered 
from the
original issue.  Also, I haven't heard of any problems lately on linux.  

If you run into any further problems getting the code to build on a particular
platform or if you'd like to provide a patch, please open a new issue.

Thanks!
--Tom

Original comment by tomf...@gmail.com on 4 Nov 2007 at 4:31

• Changed state: Fixed