LinuxQuestions.org - [SOLVED] SSH ForceCommand

- Linux - Newbie (https://www.linuxquestions.org/questions/linux-newbie-8/)

- - SSH ForceCommand (https://www.linuxquestions.org/questions/linux-newbie-8/ssh-forcecommand-4175540036/)

SSH ForceCommand

I am in the process of migrating from a Centos 5 to Centos 6 server. I have duo two factor authentication working on my original server via the ForceCommand parameter in my sshd_config file. SSH login prompts for password and immediately pushed duo authentication to phone.

On my new server, it appears the .bashrc file is executed before ForceCommand, as I migrated my .bashrc from original server to new server. This was not the case previously.

How do I force the ForceCommand to run before any profile dependent .bashrc's?

Thank you.

Quote:

Originally Posted by benjam1nrk (Post 5349162)

On my new server, it appears the .bashrc file is executed before ForceCommand, as I migrated my .bashrc from original server to new server. This was not the case previously.

Took some time finding out but here's how / why:

Code:

]$ wget http://ftp.redhat.com/redhat/linux/enterprise/6Server/en/os/SRPMS/bash-4.1.2-29.el6.src.rpm



]$ rpm2cpio bash-4.1.2-29.el6.src.rpm | cpio -idmv



]$ grep SSH_SOURCE_BASHRC -nr .

./bash-4.1/shell.c:1010:#ifdef SSH_SOURCE_BASHRC

./bash-4.1/config-top.h:91:/* #define SSH_SOURCE_BASHRC */

./bash-4.1/variables.c:570:      * I've made that behavior conditional on SSH_SOURCE_BASHRC being defined

./bash-4.1/CHANGES:3201:    run the startup files.  If the SSH_SOURCE_BASHRC is uncommented in

./bash.spec:583:- Enabling #define SSH_SOURCE_BASHRC, because ssh changed.

./bash-3.2-ssh_source_bash.patch:8:-/* #define SSH_SOURCE_BASHRC */

./bash-3.2-ssh_source_bash.patch:9:+#define SSH_SOURCE_BASHRC



]$ grep -A1 SSH_SOURCE_BASHRC bash.spec 

- Enabling #define SSH_SOURCE_BASHRC, because ssh changed.

  Resolves: #458839



]$ xdg-open "https://bugzilla.redhat.com/show_bug.cgi?id=458839"

...and there you have it. Well, the cause at least.

Quote:

Originally Posted by benjam1nrk (Post 5349162)

How do I force the ForceCommand to run before any profile dependent .bashrc's?

Three options in no particular order and without any regard for feasibility:
0) set the users shell to Something Completely Different that has no profile customizations (and use an alias or function to switch over to BASH),
1) recompile BASH and don't define SSH_SOURCE_BASHRC (which causes problems for your systems as this is now expected behaviour plus you'll spend more time maintaining as you have to recompile BASH each time its released) or
2) avoid sourcing profile-dependent stuff when running non-interactive ('bash -c') shell: see "INVOCATION" chapter in 'man bash' on what you need to do.

*I learned to avoid customizing ~/.bash* stuff long time ago and on login I manually source aliases from a non-~/.bash* file name. What may look like an extra step to some means more control to me...

Quote:

Originally Posted by unSpawn (Post 5349635)

Took some time finding out but here's how / why:

Code:

]$ wget http://ftp.redhat.com/redhat/linux/enterprise/6Server/en/os/SRPMS/bash-4.1.2-29.el6.src.rpm



]$ rpm2cpio bash-4.1.2-29.el6.src.rpm | cpio -idmv



]$ grep SSH_SOURCE_BASHRC -nr .

./bash-4.1/shell.c:1010:#ifdef SSH_SOURCE_BASHRC

./bash-4.1/config-top.h:91:/* #define SSH_SOURCE_BASHRC */

./bash-4.1/variables.c:570:      * I've made that behavior conditional on SSH_SOURCE_BASHRC being defined

./bash-4.1/CHANGES:3201:    run the startup files.  If the SSH_SOURCE_BASHRC is uncommented in

./bash.spec:583:- Enabling #define SSH_SOURCE_BASHRC, because ssh changed.

./bash-3.2-ssh_source_bash.patch:8:-/* #define SSH_SOURCE_BASHRC */

./bash-3.2-ssh_source_bash.patch:9:+#define SSH_SOURCE_BASHRC



]$ grep -A1 SSH_SOURCE_BASHRC bash.spec 

- Enabling #define SSH_SOURCE_BASHRC, because ssh changed.

  Resolves: #458839



]$ xdg-open "https://bugzilla.redhat.com/show_bug.cgi?id=458839"

...and there you have it. Well, the cause at least.

Three options in no particular order and without any regard for feasibility:
0) set the users shell to Something Completely Different that has no profile customizations (and use an alias or function to switch over to BASH),
1) recompile BASH and don't define SSH_SOURCE_BASHRC (which causes problems for your systems as this is now expected behaviour plus you'll spend more time maintaining as you have to recompile BASH each time its released) or
2) avoid sourcing profile-dependent stuff when running non-interactive ('bash -c') shell: see "INVOCATION" chapter in 'man bash' on what you need to do.

*I learned to avoid customizing ~/.bash* stuff long time ago and on login I manually source aliases from a non-~/.bash* file name. What may look like an extra step to some means more control to me...

I appreciate you taking the time to investigate, I probably would have driven myself to some degree of insanity trying to resolve.

At the end of the day, it sounds as though the ForceCommand may no longer be the best method to utilize Duo, will most likely switch to the pam module implementation.

It seems as though changing the ForceCommand implementation between releases creates somewhat of an exploitable hole, as any user with authority to modify his .bashrc file can run a custom command preceding the one specified in the ForceCommand parameter.

Quote:

Originally Posted by unSpawn (Post 5349635)

*I learned to avoid customizing ~/.bash* stuff long time ago and on login I manually source aliases from a non-~/.bash* file name. What may look like an extra step to some means more control to me...

I'd be interested to understand the benefits of this approach better... Would you mind elaborating a bit more?

Quote:

Originally Posted by joe_2000 (Post 5349827)

Would you mind elaborating a bit more?

Simply put if your environment is pristine there's no local customizations to distract or bite you. Sorry but there really isn't much more to elaborate than that.

Quote:

Originally Posted by unSpawn (Post 5352797)

Sorry but there really isn't much more to elaborate than that.

OK, thanks anyway