OpenBSD Journal

(Not so) Recent S/Key Changes

Contributed by jose on from the how-did-we-not-see-this-sooner? dept.

As part of the great setuid program audit, some programs are having their setuid bits removed in favor of a different model. Changes to the S/Key authentication mechanism are summarized in this tech@ mailing list message from Todd Miller : 
I recently committed changes to the OpenBSD S/Key code that moves
us from a single flat file (/etc/skeykeys) to a directory (/etc/skey)
where each user has a separate file.

Access to /etc/skey is controlled by the "auth" group, similar to
how the BSD authentication modules are setup.  The actual user
records are owned by the user they belong to.  This means that the
various S/Key utility programs no longer need to be setuid root,
they just need to be setgid auth.

For example:
    # ls -ld /etc/skey
    drwx-wx--T  2 root  auth  512 May 16 11:20 /etc/skey/

    # ls -l /etc/skey
    -rw-------  1 millert  wheel  42 May 16 20:43 millert

To convert from the old-style /etc/skeykeys to the /etc/skey
directory structure, simply run "skeyinit -C" and move the old
/etc/skeykeys out of the way.  E.g.
    # skeyinit -C
    /etc/skey has been populated.  NOTE: /etc/skeykeys has *not* been removed.
    It should be removed once you have verified that the new keys work.

    # mv /etc/skeykeys /etc/skeykeys.OLD
If you haven't ever checked out S/Key, you should. It provides a very secure way for remote authentication with minimal effort on your part.

(Comments are closed)

Comments

  1. By Anonymous Coward () on

    www.cryptocard.com makes cards with a simple DES encryptor. The card is programmed with a DES encryption key, and then it can be used for challenge/response authentication. It's a neat little system that is a lot more secure than passwords. Let's say I have to log in to my OpenBSD box from a friend's Windows box. OpenBSD could be 100% secure, but if a key logger happens to be running on the Windows machine, I'm screwed. One solution is to never ever do that, but another more flexible solution is s/key or Cryptocard. Both are good, but Cryptocard has some advantages for certain situations. Has anyone gotten Cryptocard to work correctly with OpenBSD/OpenSSH in recent versions? I think Cryptocard is supported in BSDAuth but I haven't heard of it being used with OpenBSD.

  2. By RC () on

    I've thought a good deal about S/Key, and am not very impressed. While it is an interesting idea, it still does not make it safe to log-in from untrusted stations.

    While someone who gets your passphrase will not be able to log-in to your server later, that wouldn't prevent a backdoored SSH *client* from sending commands to your server while you are logged in.

    In a situation where you are using S/Key over unsecure protocols (telnet, rcp, ftp) your session may still be hi-jacked by someone on the same broadcast domain as you.

    So, the only solution is still to take along your own notebook (or handheld).

  3. By francisco () on http://www.blackant.net/

    Access to /etc/skey is controlled by the "auth" group, similar to how the BSD authentication modules are setup. The actual user records are owned by the user they belong to.

    Will this potentially raise concerns with users now being able to fill /etc?

    # ls -l /etc/skey
    -rw------- 1 millert wheel 42 May 16 20:43 millert

    In the example, millert can write junk to /etc/skey/millert, filling up /etc (or rather / unless you separate / and /etc for some strange reason).

    As far as i know, there is nothing else in /etc that is allowed to be owned by a user, so this would be a new DoS to look for.
    A possible solution would be to have an skey user that creates/writes a regular user's skey file in /etc/skey

  4. By zil0g () on

    Hello, I was on vacation and missed the privsep mumbo following the apache chroot anounce.
    what I fail to realize is the problem of creating something like /etc/authports:
    # format: userid:port
    27:22 # sshd
    67:80 # apache

    etc etc

    and a (compile time) fixed number of possible entries.

    personally I think it would be neat. :)

    sorry if I'm being overly ignorant.

Latest Articles

Credits

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 deadly.org 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.]