1

A new thing I have been tasked with trying/exploring is setting up a server that will essentially have 200 to 300 people ssh'ing into a single user to run a task. They might only need to do it once a day or several times a day. The problem is that they could each connect as many devices as they want. On the outside chance that they each have 3 or 4 devices to have public ssh keys we can potentially get up to 1000 keys in the autorized_keys file. Considering that it is really only a text file a 1000 keys could potentially have a performance hit.

Is there anyway to pull this out the keys into a db or something else instead of authorized_keys file?

On curiosity note it might not be a big deal for 1000 users, but it got me wondering how someone like github can handle 500,000 users on their git@github.com user. I know I personally have 3 different keys associated to my account, and I know many others with multiple. I am not used to things of scale like this so am really curios. Is LDAP this performant to manage this? or even some kind of ssh gateway?

Buddy Lindsey
  • 269
  • 3
  • 9

1 Answers1

5

You only really need a database if you have more than 1,000,000 entries. Each key is pretty small (not even a kilobyte). As long as the file is less than, say, 20 megabytes, reading in the file is trivial (we're talking milliseconds here). Your bigger problem is load balancing. If you have hundreds of concurrent users, you're going to have problems with resources really quickly.

Your use case (1000 keys) would result in about 400 kilobytes of ssh key file. Not that big of a deal. It took my lame script 30 milliseconds to read that file. Double or triple it for parsing and it's still not a big deal.

You will need to get another server to handle the load before reading in the text file would become an issue.

In the server word, big is relative. 500,000 isn't a big deal for parsing through a text file. For example, my id_rsa.pub file is 400 bytes. Not big at all. Lets multiply this by 500,000. We get 190 megabytes. This is relatively large, but not too big. I wrote a simple NodeJS script to read in a file 174 megabytes large, and it took less than 2 seconds. This is on a regular (not server-class) hard-drive (7200 RPM), and it's not even in a raid.

SSH does not have to read in the whole file everytime, and the file would probably get cached to memory. In either case, a couple seconds of load time is not a big deal for a one-time process like SSH access.

The beauty behind github is that users don't really have SSH access. Users can only push code, and they can't connect directly to the server. This is, of course, a security issue, but it's definitely a performance issue too.

I'm pretty sure that places like github have a few servers to handle the load.

beatgammit
  • 339
  • 1
  • 10
  • That makes a lot of sense. I am fairly new to doing anything infrastructure wise, have usually taken on more of a developer role. This really gives me a lot to consider and ways to look at future tasks. The file/key size never even crossed my mind. In some cases I am so used to thinking in theoretical terms reality has to hit me in the head sometimes before I pay attention. Thanks a lot for the help. – Buddy Lindsey Apr 04 '11 at 05:14
  • Yeah, I'm a developer too, and it wasn't until recently that I realized that some optimizations really don't matter that much. Glad I could help. – beatgammit Apr 04 '11 at 05:18