I am trying to resurrect otpd, a GPL fork is here "https://code.google.com/p/otpd/. I like this thing because it allows me to run my own OTP service with OATH compliant event based tokens of almost any kind. I never got any time based tokens working and I don't really care. Years ago, I got otpd working by running it as radiusd so that FreeRadius could interact with it. This required setting all rights on all otpd related files and /var/run/otpd/socket to be owned and perm'd for radiusd. I don't know enough about LINUX to know why radiusd had to run otpd but I do remember that no matter what I did, if radiusd did not have rights to /var/run/otpd/socket then FreeRadius was always denied permission when attempting to interact with otpd. Compiling the otpd code was also a challenge because I mostly run Fedora and C files, ./configure and make files all had to be messed with. But I managed. The problem I face now though is that if I do everything I originally did as above I get all the way to authenticating and freeradius always fails the authentication and otpd seg faults. otptest executable works just fine (while running as user otpd, I haven't worked out how to use radiusd while running otptest. I always get... [root@HP-LAB-1 otpd]# su -l radiusd otptest This account is currently not available. I can use tokens and confirm that otpd is working with otptest if and only if I use root while otpd itself is running as root. The major changes that I used to make to FreeRadius configuration was: 4. Now edit the /etc/raddb/sites-available/default file and add a single line with text “otp” inside of both the authorize and authenticate sections. 5. Now add the same “otp” entries into the same sections found in the file /etc/raddb/sites_enabled/inner-tunnel. 6. Restart radiusd with “service radiusd restart”. I added otp to default and inner-tunnel like below (right underneath the heading: authorize { otp ... } authenticate { otp ... } Executing radtest... [mhawkins@HP-LAB-1 bNAC]$ radtest test1 885115 localhost 10 testing123 Sending Access-Request of id 84 to 127.0.0.1 port 1812 User-Name = "test1" User-Password = "885115" NAS-IP-Address = 127.0.0.1 NAS-Port = 10 Message-Authenticator = 0x00000000000000000000000000000000 rad_recv: Access-Reject packet from host 127.0.0.1 port 1812, id=84, length=20 Debug from freeradius looks like... rad_recv: Access-Request packet from host 127.0.0.1 port 37633, id=84, length=75 User-Name = "test1" User-Password = "885115" NAS-IP-Address = 127.0.0.1 NAS-Port = 10 Message-Authenticator = 0x54ce669945c80bffd886fce32b90a76a # Executing section authorize from file /etc/raddb/sites-enabled/default +- entering group authorize {...} rlm_otp: otp_pwe_present: password attributes 2, 2 ++[otp] returns ok ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop ++[digest] returns noop [suffix] No '@' in User-Name = "test1", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] No EAP-Message, not doing EAP ++[eap] returns noop ++[files] returns noop ++[expiration] returns noop ++[logintime] returns noop [pap] WARNING! No "known good" password found for the user. Authentication may fail because of this. ++[pap] returns noop Found Auth-Type = otp # Executing group from file /etc/raddb/sites-enabled/default +- entering group authenticate {...} rlm_otp: otp_pwe_present: password attributes 2, 2 ++[otp] returns fail Failed to authenticate the user. Using Post-Auth-Type REJECT # Executing group from file /etc/raddb/sites-enabled/default +- entering group REJECT {...} [attr_filter.access_reject] expand: %{User-Name} -> test1 attr_filter: Matched entry DEFAULT at line 11 ++[attr_filter.access_reject] returns updated Delaying reject of request 6 for 1 seconds Going to the next request Waking up in 0.9 seconds. Sending delayed reject for request 6 Sending Access-Reject of id 84 to 127.0.0.1 port 37633 Waking up in 4.9 seconds. Cleaning up request 6 ID 84 with timestamp +858 Ready to process requests. All of the above results in otpd still running. But if I run radtest once more... otpd segfaults and leaves the /var/run/otpd/socket inaccessible by radiusd. I can see that otpd passes the authentication but freeradius doesn't see it. Sep 22 22:16:59 HP-LAB-1 otpd[9352]: accept_thread: plugin accept fd=8 Sep 22 22:16:59 HP-LAB-1 otpd[9352]: work_thread(140561874147072,8): handling plugin request for [test1] Sep 22 22:16:59 HP-LAB-1 otpd[9352]: verify: user [test1] authentication succeeded So I don't know why FreeRadius is failing the authentication and I don't know why otpd is segfaulting (this is the first time I've ever had to work on an executable that does that). Any help or hints on how to solve or troubleshoot this would be *VERY* much appreciated. /Mike Hawkins
On 23 Sep 2015, at 03:31, Michael A Hawkins <mhawkins.consultant@gmail.com> wrote:
So I don't know why FreeRadius is failing the authentication and I don't know why otpd is segfaulting (this is the first time I've ever had to work on an executable that does that).
A segmentation fault is only ever caused by 2 things: * Hardware defect * Software defect As a user there's very little you can do to resolve the problem - you need to run OTP under a debugger (such as GDB), find out what part of OTPd's code is broken, and fix it.
++[otp] returns fail
FreeRADIUS believes the otp check is failing. Unfortunately it doesn't say why. What version of FreeRADIUS are you running, 3.0.x may have some better instrumentation (or the developers may be able to add some). Regards, Adam Bishop Systems Development Specialist gpg: 0x6609D460 t: +44 (0)1235 822 245 xmpp: adamb@jabber.dev.ja.net jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800.
run otpd but I do remember that no matter what I did, if radiusd did not have rights to /var/run/otpd/socket then FreeRadius was always denied permission when attempting to interact with otpd.
You could add radiusd (the user) to the group that otpd runs as (possibly 'otpd'), that way radiusd can access anything the group is allowed to access. This is something recommended when using winbindd with FR. :-)
[root@HP-LAB-1 otpd]# su -l radiusd otptest This account is currently not available.
The radiusd account has a shell that does not allow interactive login. Use su --shell=/bin/bash -l radiusd otptest :-)
All of the above results in otpd still running. But if I run radtest once more... otpd segfaults and leaves the /var/run/otpd/socket inaccessible by radiusd.
What's the actual ownership of that socket? Also... If you're running Fedora, is there any chance SELinux is messing with this? With Regards Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet Lumen House, Library Avenue, Harwell Oxford, Didcot, OX11 0SG jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Collections and Janet Ltd. is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under Company No. number 2881024, VAT No. GB 197 0632 86. The registered office is: Lumen House, Library Avenue, Harwell, Didcot, Oxfordshire, OX11 0SG. T 01235 822200.
On Sep 22, 2015, at 10:31 PM, Michael A Hawkins <mhawkins.consultant@gmail.com> wrote:
I am trying to resurrect otpd, a GPL fork is here "https://code.google.com/p/otpd/. I like this thing because it allows me to run my own OTP service with OATH compliant event based tokens of almost any kind. I never got any time based tokens working and I don't really care.
There are multiple other implementations of one-time tokens. Writing / supporting your own custom version is a lot of work.
Years ago, I got otpd working by running it as radiusd so that FreeRadius could interact with it. This required setting all rights on all otpd related files and /var/run/otpd/socket to be owned and perm'd for radiusd. I don't know enough about LINUX to know why radiusd had to run otpd but I do remember that no matter what I did, if radiusd did not have rights to /var/run/otpd/socket then FreeRadius was always denied permission when attempting to interact with otpd.
That's a red flag. If you're inexperienced with Unix security, I don't suggest maintaining your own version of OTPd.
Compiling the otpd code was also a challenge because I mostly run Fedora and C files, ./configure and make files all had to be messed with. But I managed.
"Messed with" is also a red flag. You should understand what you're changing, and why.
The problem I face now though is that if I do everything I originally did as above I get all the way to authenticating and freeradius always fails the authentication and otpd seg faults.
Seg faults indicate coding errors. You "messed with" the code and broke it. That's bad.
All of the above results in otpd still running. But if I run radtest once more... otpd segfaults and leaves the /var/run/otpd/socket inaccessible by radiusd.
Because otdp isn't running.
I can see that otpd passes the authentication but freeradius doesn't see it.
The rlm_otp module returns "fail" for some reason. You'll have to root through the source code of rlm_otp to figure out why.
So I don't know why FreeRadius is failing the authentication and I don't know why otpd is segfaulting (this is the first time I've ever had to work on an executable that does that).
It won't be the last.
Any help or hints on how to solve or troubleshoot this would be *VERY* much appreciated.
Writing and debugging C programs is hard. This list isn't really the place to describe how to do that. My suggestion is to toss otpd, and go with software which is actively maintained. Because otpd isn't supported any more, we don't really support rlm_otp. And we're going to remove it in a future release. Alan DeKok.
participants (4)
-
Adam Bishop -
Alan DeKok -
Michael A Hawkins -
Stefan Paetow