0

Background: I added OTP token authentication to my web server. I modified the /etc/ssh/sshd_config file with the ForceCommand /token/script command.

Problem: I have a local Jenkins instance connecting to the web server for doing deployments; Jenkins can't enter token info or respond to phone calls (although who knows, I bet there's even a plugin for that!).

Possible solution: use the ~/user/authorized_keys command parameter to force the token script on all keys, except for the key being used by jenkins.

Question: How less secure than the global sshd_config approach the authorized_keys approach is? Would you consider it an acceptable trade-off? Is there a better solution (that allows Jenkins to do slave deployments, whilst keeping everyone else locked down with token auth?).

I've tried both approaches and both work like a charm. The second approach I find more practical in terms of deployments, but it raises some sort of internal red flags for me. I don't know if I'm chasing ghosts (with the red flags). Discuss!

amateur barista
  • 498
  • 3
  • 7
  • 21
  • FYI, part of this question has been answered before [here](http://serverfault.com/q/162467/73145), and the answer basically is yes, authorized_keys is less secure? On the other hand, how would you allow Jenkins access without compromising token access (as when you use auhorized_keys)? – amateur barista Aug 07 '12 at 22:49

1 Answers1

2

Use the Match command in your sshd_config to apply different rules to the jenkins user than you do to other users:

  • Match: Introduces a conditional block. If all of the criteria on the Match line are satisfied, the keywords on the following lines override those set in the global section of the config file, until either another Match line or the end of the file.

See the sshd_config man page for complete documentation.

larsks
  • 43,623
  • 14
  • 121
  • 180