Linux expect not returning control to bash script after using interact

The problem you have is that the various layers of communication have to remain in place; there's more going on than you're aware of.

Your model is this:

+------+   expect   +-----+   su   +----------------+
| bash | ---------> | ssh | -----> | remote-context | 
+------+            +-----+        +----------------+

But what's actually going on is this:

+----------------+   +----------------------+   +----------------------------+
| local terminal |   |        expect        |   |       remote terminal      |
|                |   | +------------------+ |   | +------------------------+ |
|    +------+    |   | | virtual terminal | |   | |          bash          | |
|    | bash | -----> | |                  | |   | | +--------------------+ | |
|    +------+    |   | |     +-----+      | |   | | |         su         | | |
|                |   | |     | ssh | ---------> | | | +----------------+ | | |
+----------------+   | |     +-----+      | |   | | | | remote context | | | |
                     | +------------------+ |   | | | +----------------+ | | |
                     +----------------------+   | | +--------------------+ | |
                                                | +------------------------+ |
                                                +----------------------------+

Or something like that (I've omitted most of the bits to do with the network, for example). There's a lot of layering going on, most of which you're unaware of. But because ssh is running inside expect (in order to take advantage of the automation capabilities) it means that ssh is running in a local virtual terminal controlled by expect; bash can't take control directly, and expect can't cut itself out of the loop (since bash doesn't know how to be the master side of a virtual terminal; expect and sshd do know that).

Instead, you need to either write the remainder of your code inside expect directly, or provide the code that is to be run as an argument (in some sense; perhaps pulled from a file?) that it can pass on via send.

Expect gets arguments from the argv variable, can use gets stdin to read a line of text from its caller, and open/read/close to pull in the contents of a file.

Are you aware of sudo as an alternative to su? That can be configured to allow fully password-free operation for a particular requesting user. That can be useful to allow operation of the system without exposing too large a security hole. You should also consider switching to a form of ssh that works better for automation, such as:

spawn ssh $remotehost sudo /usr/local/bin/DoTheWonderfulThing

This sort of thing, once it works, has fewer pieces that can go wrong in unexpected ways…