Dist: Fedora 14
SSHD: OpenSSH 5.5p1

I need to limit the number of ssh connections a user has. All the users are using tunnel only so their shell is set to /sbin/nologin

The logins do not open a shell they just create the tunnel so /etc/security/limits.conf has no effect on them at all.

I tried setting 'MaxSessions 1' in sshd_config but either that doesn't not do what I expect it to or it plain does not work as even with a normal user I was able to open an unlimited number of sessions.

I need a good secure way to limit each user to 1 ssh session without them having a shell but Im unable to find a solution.

I believe you can actually use /etc/security/limits.conf but you have tu use the pam_limits module in your ssh authentication.
add this line to /etc/pam.d/sshd:
session required pam_limits.so
and configure your ssh daemon to use pam for authentication (UsePAM yes in /etc/ssh/sshd_config)
I believe this should work.

Unfortunately this does not work. There is no actual session since a shell is never opened. You have to distinguish between 'session' and 'connection'. The other problem is pam never gets used with key authentications it seems.

This becomes a very large problem is you are using portable putty on a flash drive. If someone loses their flash drive then the finder can essentially ddos the server by spreading the key over a botnet. If you were able to limit the ssh connections(not sessions) this problem goes away. I wish the documentation for openssh better described what they mean by sessions and connections. I do know from experimenting that you can limit ssh to 0 sessions but still create a connection and have a tunnel. In fact you can create enough to bring the system down.

In this particular case I can not allow the users direct shell access of any kind so their accounts must stay /sbin/nologin, but I can not seem to find a way to limit them to a single ssh connection per user. I can do it per ip but in the instance of a botnet that is useless.

How are the users being validated? Depending on that, you could always put something in to lock their account, so if they try to open a second connection, it'll fail at the authentication stage.

Users are being validated using pre-assigned keys with the public of the pair in ~user/.ssh/authorized_keys as this is the preferred method outlined in every document on ssh I've read.

In most of the cases the client is putty portable creating an ssh tunnel for secure web browsing using only username and ssh key, with no shell being started and all users having their shell set to /sbin/nologin, which doesn't matter since the shell is never started.

That's a tough one, alright. I guess you could write something to look for when a user attaches, and have it rename the keys file to something else, which would cause any subsequent connections to die. Just a thought...grasping right now.

Yes if you write something to wrap ssh there are many options, of course at that point you could also just rewrite an implementation of ssh. I have an email out to the OpenSSH team but have not heard back yet. It seems to me that a malicious user with a valid key could easily bring a machine down because you can make any number of authenticated connections. At this point ssh only allows you to limit 'sessions' and 'unauthenticated connections' and iptables is unable to see the 'user' so you cant do anything there and without the user being logged in you need to start writing kernel modules or wrappers around ssh. Granted this isn't the biggest security issue but it could be troublesome if you get a disgruntle user with key that hasn't ben deactivated.

Hopefully someone else will have some ideas or the OpenSSH team will get back to me.

I didn't think about it. It does not work if you use key authentication that do not use PAM indeed.
I can only think about a messy script running in cron and killing ssh processes based on netstat.
Maybe that is possible using the GSSAPI?

I will look into GSSAPI as I know nothing about it. The problem with using username/password is it's highly susceptible to man-in-the-middle attacks. This wouldn't be a problem if you could trust all your users were smart enough when using putty to not accept new host keys. The fact that putty has no facility I know of to just refuse unknown host keys is just plain bad. So I'm left trying to find a server side solution for the windows users connecting. This isn't a problem if the clients were running linux I could just use host keys and then use password authentication over that and the pam limits would work just fine. I know this moves away from the whole 'Linux' questions, but if anyone knows of another free ssh client with such features that I can freely give to clients using my server I would appreciate that knowledge.

Hi
I'm having the same problem, limiting SSH connections(not sessions) per user seems impossible and I desperately need that for my SSH tunnel server.
Users use SSH clients such as Bitvise Tunnelier or Putty to establish connections and forward their traffic through SSH tunnel and each user has specific user name and password but the problem is that they can use the same log in information for creating several connections and I need to limit the number of connections. Unfortunately 'MaxSessions 1' and /etc/security/limits.conf does not work for me.
Your help is highly appreciated.

I had to resort to writing a login shell and a cron script. My login shell works like nologin but checks to make sure each user is only logged in once. I did that because not all OSes have a way to limit this. The cron scrip just looks for any ssh connections that are not associated with a login shell and kills them. I dont know if this helps you at all. I wrote all the code for a specific company and I need to make sure I have permission to make it open source, which I think they are ok with anyway. However it may not suit your needs.

Thanks for the quick reply, I think I should do the same thing and write a shell script and set a cron job. I really appreciate it if you could share your script or at least give me some tips about it for example how to find concurrent connections with same log in information.
thanks in advance

Sepcifying a passphrase will at least put the burden on the finder to crack it before he can use it. Unfortunately there is nothing in the publickey which would indicate whether a passphrase was used, as the passphrase protects only the private part.

Not sure if it would work, but have you tried running sshd under xinetd? Then in /etc/xinetd.d/sshd you can set "per_source = 1"