Test the upstream fix for repeating banner messages issue from upstream.

We’ve observed that when connecting via sshpiper, if the user is in a deny group, the banner message is displayed repeatedly even if the connection was closed by the upstream server.

This differs from a direct ssh connection to the server, where the banner is shown only once and the connection is closed immediately.

Refer to the issue https://github.com/tg123/sshpiper/issues/593 for more details.

The author provided a fix for it upstream - https://github.com/tg123/sshpiper/pull/594. We need to test if it is acceptable to us in staging

added Sprint 25-11 label

changed milestone to %Cutover to proxy nodes for production Cheaha access

changed the description

We have deployed the ssh proxy in staging. It is working as expected.

The ssh proxy was built from the upstream sshpiper HEAD. The following features were tested:

We tested the upstream-banner-mode option with dedup (only display once per banner), and first-only(display only first banner) modes. We now see that the upstream banner message is only displayed once to the end-user in the terminal. Just FYI, passthrough is the default.

changed title from Verify sshpiper show banner message from upstream to Test the fix for repeating banner messages issue from upstream.

changed the description

mentioned in issue #236 (closed)

assigned to @atlurie

Here's how we tested in staging.

### Update your /etc/hosts to point to the ssh-proxy in your staging
138.26.x.x cheaha.rc.uab.edu

### Put the account on hold/certification
ssh root@<HEAD_NODE_IP>
cd /cm/shared/rabbitmq_agents
source venv/bin/activate
./group_manager.py -g hold BlazerID
exit

ssh BlazerID@cheaha.rc.uab.edu

### You should see a message like this,
Your account is currently on hold.
Please contact Research Computing at support@listserv.uab.edu to resolve this issue.

### To remove your account from hold, run this on HeadNode
./group_manager.py -d -g hold BlazerID

There's a script for hold or certification state:

# put the account on hold 
./account_manager.py <username> hold

# put the account for certification state
./account_manager.py <username> certification

# put the account for ok state
./account_manager.py <username> ok

We tested on the ssh-proxy node, and verified that the message from Denygroup only printed once.

However, the user still got banned since sshpiper still retrys till the failtoban-plugin kicks in.

mentioned in issue devops#603 (closed)

To avoid the user getting banned we need to have a workaround before a formal fix is in place. See linked item for more details

Currently, we resolved this by defining a ForceCommand exit in our backend sshd_config Matchgroups section (used to match the client in a special group), which we use to deny access to the cluster.

So any user matching one of those special groups will get a connection, but will be immediately forced to exit their ssh session, and the connection will be closed.

changed the description

changed title from Test the fix for repeating banner messages issue from upstream. to Test the upstream fix for repeating banner messages issue from upstream.

marked this issue as related to devops#628

closed