Hello,
I'm trying to limit the concurrent ssh connection number for several accounts. These accounts are only used for SSH Tunelling.

I tried to do this by setting a hard limit on /etc/security/limits.conf. The "maxlogins" option in this file fits my requirements perfectly.

However, I then found that this option is not working for all SSH clients.

I'm connecting to this Debian server from Windows. I tried putty first, it works well. When the number of ssh sessions under the specific user acheived the limit, the next login with this account will fail.

But when I try another ssh client named "Bitvise SSH Client", the limit doesn't work at all. For exaple, the limit is set to 1 for user "TestUser", but I can connect with 3 Bitvise clients with no problem.

With Bitvise client connected, I run "users" command on the server and show no TestUser instances at all. However, if I use "pgrep -u TestUser sshd", I can still get the correct number of processes.

Could anyone help me on this problem? Or is there another workaround? Thanks!

My server is Debian squeeze with default sshd (should be openssh). All my tests are using ssh2.

It isn't the client that controls that, but the server.

The usual problem is identifying what a "session" is. Usually, sessions are only counted if they are interactive login sessions. But that permits as many scp/ssh connections as desired as long as they are not interactive - normally, determined by whether a pty is allocated or not, as USUALLY these get marked in the utmp/wtmp file - and thus can be counted.

Otherwise, I don't think there is a way to make such a limit enforceable.

Hello jpollard,

Thank you for your reply!

So is there other way to limit the non-interactive connections?

I tried the .bashrc script (.profile on Debian), it seems the script is not processed for non-interactive connections either?

But since it could do SSH Tunelling, and has its own PID, there must be some way to control it.

I think at least I can make a daemon process on root account to recurrently check the PIDs for the specified users and kill the processes above the limit. But I'd like to see if there is other tidy and efficient way to control it...

Not really. Part of the problem is that any process put in the background is "non-interactive". The only distinguishing difference is that the parent process would be sshd...

One other problem is if the sshd is used only for the tunnel - there are no user processes... Only sshd to set up the tunnel. If the ssh -N option is used, then there are no user processes. The login is only for the purpose of authorizing the tunnel, and no user shell is created.
No - the only thing needed is the base setup. the only thing executed is the command passed (or the scp command as the service) and no terminal is allocated (thus, not interactive). One of the things that causes problems is that the .profile tends to try to set terminal conditions (terminal type, sometimes even output messages), and that causes protocol errors.

There are some references to getting it to do that:
http://community.centrify.com/t5/Cen...and/td-p/16436

But note: they don't work if the -N option is used to setup only the tunnel.
You don't know which one to kill... pids recycle, so you don't know which is earlier, and processing the stime field of ps is going to get a bit difficult (it gets truncated, and has a variety of formats entered). I guess it is doable, but I think it would be error prone. Second, a user process doesn't have to even appear (the -N option).

2 members found this post helpful.

Thank you jpollard,
Your reply is very helpful! I will try investigate other solutions later.

You might investigate PAM. I believe sshd uses PAM for authentication, and you may be able to write a module that performs the counts after a success. That way it wouldn't matter if it were interactive or not - but you would be able to terminate the connection when a user exceeds their limit.

Something like:

http://manpages.ubuntu.com/manpages/...m_tally.8.html

could form a starting point. It is aimed at counting failures, and locking the account when login errors exceed a count limit. Yours would be trying to track active counts instead.

I'm not sure how to decrement a count though. Sshd doesn't have a termination PAM module. There does appear to be something like that for interactive use of of terminals - that is how the utmp and wtmp files register/unregister ttys. I admit the tty thing is error prone, as aborted sessions don't get unregistered.

Found another possibility:

http://www.linux-pam.org/Linux-PAM-h...am_limits.html

The "maxlogins" option might work for you without having to create your own module.

1 members found this post helpful.

Thank you very much, jpollard.

I will try write my own PAM module, and see if it works.

About "maxlogins", I have tried in my original post, it doesn't always work on my OS. All the Bitvise clients are not counted, no matter interactive or not. So I had to give it up.

I wasn't sure it would work. The problem is that the module definitely gets called on login... But not on logout.

There is an extreme possibility to catch the logout - one is to impose an alternate process reaper that cleans up when a process terminates. On login, the sshd process gets tagged with a different reaper, and the pid+userid are used as keys - in the PAM module the userid is checked against the uid limit(and counted if below), the pid is recorded with the userid so that when the death of a child is caught by the reaper process, the pid can be used to retrieve the uid; which can then be used to decrement the count. If the pid doesn't have an entry, then it is not the one that will be counted down (it is just another process) and cleaned up without doing anything else. This is similar to the PAM module, but using an alternate reaper to ensure the count is tracked.

This is identified in http://man7.org/linux/man-pages/man2/prctl.2.html

Unfortunately, there aren't any simple examples of using it. All of the examples I have found have always been part of the cleanup from complex init processing (systemd uses it for cleanup of credential caching, I believe Openrc/upstart does similar things).

What I'm not sure of with this is how it would interact with the version of the reaper provided by the system...or even if it needs to.

One complication here is that if you are counting tunnels and sessions from a single client PC, that PC may have code that subverts your intent.
Recent versions of some ssh clients (The beta putty is one example) have an option to reuse connections. IE: if you already have one ssl tunnel to a remote machine (tunnel or session) and you start a second (session or tunnel) then the second simply adds its traffic to the pre-existing tunnel rather than open a new one.
If you have set ssh to use PAM (it is an option, not locked in) then the authenticate steps will still take effect. If you are using tools or options that detect the connection, there is not a new one so that will be bypassed!
I have not researched the latest OpenSSH documentation. There are new settings and controls in the newest versions that may pertain. Alas, you may have to bypass testing, and even unstable, and compile from source to get that version.

quite. But it is still using a single tunnel, thus could still be counted as "1". But that would be up to a management decision as to whether that would be violating the rules. Besides, if PAM is used, then the count could still be maintained. The issue would still remain if the existing sshd is also used to establish the additional ports (which would make it harder to track) or if it used a new sshd to establish those ports. If it used the existing sshd, then I would say that still counts as a "1" (and the tracking software would be able to detect it as the pid would already be in the tables).