Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

I got my GSSAPI authentication working. But, wondering how one restrict
users (if i want to) in reaching my hosts.

My setup:
SSH Server: HP-UX Secure Shell 4.0 (based OpenSSH 4.x)
KDC: Windows 2003
SSH Clients: Putty at this time.
(some how, F-secure SSH client some how not working with GSSAPI)

What I am looking for is:

AllowGroups/AllowUsers/DenyUsers based on their type of authentication.

DenyUsers GSSAPI *
AllowGroups GSSAPI my_friends

Other option for me, restrict at service ticket level from Windows AD
2003 level. I am not sure how and is it possible?

Say i have global group in AD called "my friends":
Add my friends to "my friends" group and only users in "my friends"
group will get Service ticket for my HP-UX box.

Can any one give me right pointers in this.

any help in this regards will be helpful to me



Quoted text here. Click to load it

OpenSSH does not have this flexibility.  In fact, I don't know of any SSH
server that does; it is one of the most long-standing inadequacies of most
SSH software, IMO.  Authorization is usually completely ad-hoc and full of
random pointless restrictions -- e.g. most of the fine-grained
authorization controls in OpenSSH are only available if the client has
used publickey authentication, for the simple reasons that it's
implemented with options in the authorized_keys file.

Tectia took a step in the right direction with its
ExternalAuthorizationProgram option -- but even that is inadequate as it
stands, as the server passes very little information to the program!  It
doesn't even distinguish between authid and authzid, let alone specify the
authentication method used.

I recall some talk early on about using KeyNote in OpenSSH, but don't know
what the status of that is.

Quoted text here. Click to load it

I don't know if the Windows KDC can do this, but KDCs generally don't,
because this isn't the right way to address this need.  The term "service
ticket" is misleading: it sounds as if the ticket provides permission to
use the service, i.e. authorization.  It doesn't.  The purpose of Kerberos
is authentication: the service ticket merely identifies one principal to
another, in this case authenticating a user to a server.  The server's
decision of whether to allow the user access, once identified, is
authorization -- a completely separate process.  Sure, you can deny
someone access to a service by refusing them authentication, but it's a
bit heavy-handed and causes other problem.  As a scheme it happens to work
better with Kerberos than other systems due to the per-service
credentials, but still, it's not usually done.

  Richard Silverman


Quoted text here. Click to load it

The patches for this are several year old and I'm not sure they're even
available online any more.  There's been no recent movement in that
direction that I'm aware of and I believe there would be a significant
amount of work involved to bring them up to speed.

Darren Tucker (dtucker at
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.


Quoted text here. Click to load it

Mean while I sent a mail to our Microsoft support and still waiting.
Will update if .. its +ve

And patch:
May be this one ?!

Auth selection /

 #LoginGraceTime 2m
 #PermitRootLogin yes
 #StrictModes yes
 #MaxAuthTries 6

+# Auth selection
+#ChallRespAuthAllowUsers [pam] user1 user2 ...
+#ChallRespAuthDenyUsers  [pam] user1 user2 ...
+#ChallRespAuthAllowUsers [bsdauth] user1 user2 ...
+#ChallRespAuthDenyUsers  [bsdauth] user1 user2 ...
+#ChallRespAuthAllowUsers [skey] user1 user2 ...
+#ChallRespAuthDenyUsers  [skey] user1 user2 ...
+#ChallRespAuthAllowUsers [securid] user1 user2 ...
+#ChallRespAuthDenyUsers  [securid] user1 user2 ...
 #RSAAuthentication yes
 #PubkeyAuthentication yes
 #AuthorizedKeysFile    .ssh/authorized_keys


Site Timeline