With ssh, how can you run a command on the remote machine without exiting?

Question

Normally, if you pass a command to ssh like so

ssh [e-mail] 'some-command.sh'

You get a non-interactive session, and ssh exits as soon as the command (or script, or whatever) is run. How can I get an interactive session, and yet run a command that I've specified from my local machine. For instance, I'd like to be able to open screen and restart a specific screen session:

ssh [e-mail] 'screen -r 12345'

but this is not allowed, returning the error "Must be connected to a terminal." which I presume means essentially "must call this command from an interactive shell".

As another example, I use a ton of machines at work that often require me to use a shared account to have rights to do certain things (yeah I know: bad idea but don't blame me, I didn't set things up that way), and they usually have ksh as the default shell. I'd like to log in, switch to bash (or zsh), and source my own account's .bash_profile (or .zshrc). This would be easy if I could establish an interactive ssh session and pass a command to the remote machine to run upon login.

I have a very kludgey (and untested) solution in mind that I will post, but I'm hoping someone knows a better way.

UPDATE: for those who didn't realize this, I'm not planning to do all this by hand, so telling me to open an interactive session and then do it by hand doesn't actually solve anything.

2nd UPDATE: To attempt once again to clarify: I'm trying to run (arbitrary) commands on the server (programmatically specified on the client) but then have an interactive session open that is affected by anything done by those programmatic commands.

Answer 1

This is kludgey, and untested, but I think it should work.

Create a script named (e.g.) remote-starter that takes a quoted argument after a user@host argument:

remote-starter [e-mail] 'some-command.sh arg1 arg2'

This script should first save the quoted command (without quotes) in file named (e.g.) .onetime on the remote machine, and then run a regular ssh command, this time not passing any command to be run on the remote machine. (If running ssh [e-mail] from within a script, it may work to run exec ssh [e-mail].)

For this to work, the remote machine must source .onetime from its .bash_profile or .zshrc or whatever. After running .onetime, it should delete .onetime, so the file is not run the following time you do a regular login.

Answer 2

You can try the following command to start up bash and source your own profile when you ssh:

ssh  -t hostname "bash --rcfile ~user/.bashrc"

Answer 3

Building on dogbane's answer, a complete solution looks like:

ssh -t user@server 'cd /a/great/place; bash'

Here I use -t to force the allocation of a pseudo-terminal, which is required for an interactive shell. Then I execute two commands on the server: first the thing I wanted to do prior to opening the interactive shell (in my case, changing directory to a specific folder), and then the interactive shell itself. bash sees that it has a pseudo-terminal and responds interactively.

The single quotes ensure the entire thing is passed to the remote server as the command to be run by your default shell.

Thanks again to dogbane for providing the necessary clue with -t. I used to solve this problem with expect, which is definitely killing a mouse with a cannon. (:

Answer 4

Try this solution.

echo "command" | ssh user@remote_host

The login is interactive and your command is passed as if you typed it on the interactive command line. The session terminates as if you had typed

ssh user@remote_host 'command'

Answer 5

Use ssh -X to use termIO cmds.

Also - you can chain your cmds like "ssh 'source ~/.bashrc && cd && do '"

Answer 6

why not install detach on the remote system and use:

ssh -t [e-mail] "/home/user/bin/detach ls"

Answer 7

laggingreflex's answer is close... I'd change it as follows:

echo "command\n$(cat -)" | ssh user@remote_host

Unfortunately, you're not likely to like the way that works, 'cause "cat" buffers the lines it writes to stdout... If we create a script called "echo-cat" that looks something like this:

{
  echo "${@}"
 #cat buffers & won't flush to stdout immediately
 #cat -
  IFS='\n'
  while read line
  do
        echo "${line}"
  done
}

we'll get the same result without the buffering:

echo-cat "command" | ssh user@remote_host

That'll probably get you a lot closer to your objective...