OpenBSD Journal

SecurID support for OpenSSH

Contributed by jose on from the token-based-security dept. writes: Vaclav Tomec has implemented SecurID authentication for the official portable release of OpenSSH in the form of a downloadable patch. SecurID® authentication is based on something you know (a password or PIN), and something you have (an authenticator) - providing a much more reliable level of user authentication than reusable password. His patch is made as challenge response authentication and authentication (a non-standard solution provided in commercial implementations from F-Secure and SSH) with full privilege separation support. Vaclav says that you can find another (different) implementation and Theo's patch, which makes possible use of SecurID tokens in OpenSSH, but his solution is very simple one and implemented as a hack into password authentication."

The patch needs a bit more cleanup, but you can help by testing his patch (if you have the right hardware). This would be pretty neat, and allow for OpenSSH to be a more central role in some authentication systems.

(Comments are closed)

  1. By CoolHandLuke () on

    Too bad there is no support for SecurID on OpenBSD. It seems only the HP-UX, Linux, Solaris, and AIX folks can utilize this solution for now.

  2. By Shuasha () on

    I'm sure that this is all proprietary hardware/software.. but has anybody thought of an open source SecureID server, then just buying the cards from RSA? Is this even possible?

    1. By Petr R. () on

      No, it is not possible AFAIK. Cards numbers has to be imported to ACE server and in this way server knows what number will follow on card. However, ACE server could work as Radius, so it should be possible to use it in this way.

    2. By Anonymous Coward () on

      It is called a "Cryptocard", from It is a totally open standard and doesn't require a server. This is way cooler than SecureID.

      1. By Anonymous Coward () on

        This is not an open source solution.

        1. By Guruh () on

          If it has an open standard defined that is not encumberd with patents and such it might be an idea to write a open source alternative for the server software. I cannot find any standarddocuments on the site thou. If anyone finds any would you be so kind and post a link to them in this thread?

          1. By Nonesuch () on

            SecurID is the only vendor offering a time-based token solution. As mentioned before, it would be possible to integrate SecurID into OpenBSD by using RADIUS.

            There is the old "Secure Net Key" (SNK) standard, but that uses a simple MD5 hash and has been demonstrated to be fatally flawed.

            The CrytoCard and Safeword authentication tokens both offer a SNK mode.

          2. By Anonymous Coward () on

            I had some of those and played around with them. There is no documentation of what they are doing, but it doesn't take long to confirm that they are doing plain old DES encryption. They DES key is entered as the key of the card, and it is used to encrypt the challenge to form the response. That's all it does. There are no patents on any of this, and none of it is proprietary. I wrote a C version of the Cryptocard in about five lines of code. This is why OpenSSH should be using this, instead of SecureID. Cryptocard may not be documented but the algorithm is totally unencumbered, free and trivial to implement.

            1. By Ben () on

              5 lines of code? Amazing consider every Cryptocard patch I've seen has been on the same complexity as the existing Smartcard support. Which brings up a question... What is wrong with smartcard? It is pretty cheap technology. It is an open standard and the media is a pricy, but bad.

      2. By Robbo () on

        Where did you see the specs for the "Open"
        CryptoCard stuff?

        I am interested to use a big box of the cards, but do not have any PAM modules for OpenBSD.

        Any pointers would be appreciated,



  3. By Anonymous Coward () on

    I got this running under Solaris. Works like a charm.

    Solaris 9 (64bit SPARC), gcc v3.2 (had to use gnu's strip v2.11.2 for the ELF issue with gcc's strip), ssh 3.6.1p2, this securid patch, openssl 0.9.6g, zlib-1.1.3, ACE SDK 5.0.2 (copied the contents of the CD to a directory under /usr/local).

    You must configure with the --with-securid=/usr/local/SDKPATH option. Then you must get your ACE server to create the handy ol' sdconf.rec file and put that locally (I used /usr/local/etc). Then you set the right options in sshd_config and start up sshd.

    I tried the latest and greatest PUTTY. I had to specify SSH2 as the preferred method. Keyboard Interactive is set by default on the PUTTY I grabbed.

    Using the version of ssh compiled with the patch works fine.

    Using an old version of openssh (v2.1.1 and v2.5.1) won't work because they don't support keyboard interactive authentication (not until this patch, that is).

    This is a big help. We use neoteris to connect from the outside (that and Checkpoint's Secure client) and I can't get their (Neoteris') java ssh client to work with any of my Win XP personal, OpenBSD 3.1 or MacOS 10.2.x boxen. Only my XP Professional (with the Microsoft JVM, before the court forced them to yank it) works with neoteris. At least now I can recompile OpenSSH on my Mac and OpenBSD boxen and use that! We don't like the idea of leaving ssh with just plain old passwords listening on the outside net.

  4. By RC () on

    Anyone want to comment on how this is any more secure than S/Key?

    1. By Anonymous Coward () on

      Because you're not carrying around a sheet of paper with 10 passwords written on it. Or a postit note stuck to your laptop when it's stolen.

      1. By Anonymous Coward () on

        You can use tools like pilOTP on Palms to
        generate passwords when needed.

      2. By RC () on

        You don't need to print that stuff out... You can keep the program on your laptop or handheld. It's not CPU-intensive either, I'm sure if it was popular, a company would come out with a tiny computer that just generates S/Key passwords.

        With "Secure" ID systems, there have been a few attacks that can potentially suck the private key out of it... With S/Key, it's not possible, because you type in the private password yourself, it never exists on the device. So, someone would have to steal your handheld with the S/Key software, install a key-logger, return the device without you noticing, and then steal it again, to retrieve the logs.

        1. By Nonesuch () on

          There are attacks against the RSA SecurID software token for Palm (and probably for windows). Any system that uses software that resides on a multi-purpose machine, including S/Key, will be vulnerable to these attacks.

          What most people are thinking of (and what security minded people deploy) is the self-contained SecurID "hardware token", available in a card or "key fob" form.

          There are other vendors that produce "key fob" hardware tokens, but SecurID is the market leader with their time-synchronous tokens. Most other products are challenge-response or event synchronous, both of which tend to result in complaints from users....

          1. By RC () on

            Fine, fine... I don't feel like arguing this point.

            Now, assuming tha SecurID and S/Key are equally as (un)exploitable, what is the advantage to using SecurID?

  5. By Anonymous Coward () on

    I wish that standard OpenSSH had support for Cryptocard. There was a patch that did this a couple of years ago but the OpenSSH developers refused to merge it. For those who don't know... Cryptocard uses plain old DES to do challenge-response. It's a completely open standard and the Cryptocards themselves are cheap, and don't require an investment in some kind of server or configuration device. For those of us who want something stronger than just plain old passwords, but don't want to mess around with S/key, Cryptocard is the way to go. I wish OpenSSH supported it.

  6. By djm () on

    You shouldn't need to patch OpenSSH to give it new challenge-response authentication methods. The best way under OpenBSD is to write a new BSD auth helper (/usr/libexec/auth/login_*). These are standalone programs and are the best way to add new authentication methods to OpenBSD.

    If you run OpenSSH on another platform, you can use a PAM module instead. I think that a secureID PAM module already exists.

    (of course, I'd prefer to see the BSD auth framework ported to other platforms, it is way nicer than PAM.)

  7. By Anonymous Coward () on

    A patch for this actually exists for a long time. There seem to be 2 projects regarding this. This projects exists according to FM at least since jan. 2001 since it was added in their DB at that moment:

    And this is the new project which is covered up by

    There are also a few other OpenSSH patches which might be useful for example an LDAP patch and a SRP patch:§ion=projects

    I've been using the LDAP patch for a while on Linux. I like it more then PAM.

  8. By tom hensel () on

    just to note it...

    o RSA ACE/Agent version 5.0 for Windows
    o RSA ACE/Agent version 5.x for Web

  9. By Jack Rabbit Slim () on

    OpenSSH-3.7.1 works out of the box with SecurID where RSA provides PAM modules for your OS (Solaris, HP-UX, etc.). However, you cannot run the standard OpenSSH build with privilege separation enabled, which is where Vaclav's code comes in. I'm doing our build on Sol9, and the only feature that I am currently taking advantage of with Vaclav's code is the PrivSep fun - I have been *unable* to get the patched ossh build to allow for new PIN creation or to work when a rekey is requested, although Vaclav claims that these features are working. Another thing to note is that you do not need the ACE PAM library if you use Vaclav's code...

    The sad part about this is that RSA has been absolutely no help whatsoever with getting their shit to work with OpenSSH - in fact, the guides they gave me were surprisingly full of errors (like assigning rlogin() instead of sshd() in Solaris' and RedHat's PAM control files.. really silly stuff).

Latest Articles


Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]