Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I would like to do something like ssh 'ls' However per ssh manpage:

If command is specified, it is executed on the remote host instead of a login shell.

So what happens is that ls displays it's output and then ssh exits.

What I can't figure out is how to have the full login shell open and then have the command run inside that shell. Leaving the shell open after the command is run. As if I had manually done the following:

  localhost$ ssh$ ls
             /folder2$ _

Any ideas?

share|improve this question
this is a similar question… but none of the answers really seem to fit what I'm trying to do. – matthew Jul 5 '11 at 14:16
How about ssh 'ls;bash'? – Andrejs Cainikovs Jul 5 '11 at 14:40
you need the -i on my systems to make the second shell an interactive one. – Flexo Jul 5 '11 at 15:01
option -t is the answer to your question. Other options (for example keychain) exist but depends on your real needs, which are not clear enough to me . – hornetbzz Jul 5 '11 at 23:33
@hornetbzz -t gives me pseudo-tty. But otherwise the behavior is the same. I want to launch an interactive shell, run a command inside that shell and have the shell remain open after the command is run. – matthew Jul 6 '11 at 3:50
up vote 12 down vote accepted

Just tell bash to execute ls and then itself in a login shell

$ ssh user@host  -t 'bash -l -c "ls;bash"'
share|improve this answer
Unfortunately this doesn't appear to work while using screen. Otherwise this seems like it does what I was trying to do. – matthew Jul 17 '13 at 17:57
ssh user@host -t 'ls; exec $SHELL -l'

-t Force pseudo-terminal allocation. This can be used to execute arbitrary screen-based programs on a remote machine. Is slightly more proper than bash -i.

exec No new process is created.

-l looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from ... Without this you probably can not run scripts/commands from ~/bin directory, because this code from ~/.profile will not be executed without -l flag:

if [ -d "$HOME/bin" ] ; then
share|improve this answer
@grawity @Alan This might work as a workaround, but I'd really like the command to run inside the shell and not just open a new shell after the command is run. – matthew Jul 5 '11 at 15:46
+1, -t is definitely the right way to go over -i, I just forgot about it. – Flexo Jul 5 '11 at 15:50
@matthew: You'll have to patch bash yourself to allow that. – grawity Jul 6 '11 at 14:34
@grawity not really, see my answer below – fons Jul 17 '13 at 15:59
@matthew, use exec bash or exec $SHELL – Eugen Konkov Mar 1 at 8:44

In your comment on fons's answer, you say that it doesn't work while using screen.

Could you elaborate on that? Looking at the source code for openssh, sshd executes the command by calling


So, for example, if your default shell is screen, then this won't work all that well because screen's -c flag just overrides its .scrreenrc. So, there's really no way to send commands to screen if it's your default shell. You'll have to actually run screen as the command given to ssh, but with a default shell that isn't screen.

If that's what you're trying to do, I think things will get really weird, since screen will also close windows with non-interactive programs, so you'll have to do a similar trick to fons's, but one level deeper. SO, with, e.g. /bin/bash (and not screen) as your default shell Something like:

ssh user@host -t 'screen bash -l -c "ls;bash"'

Which should --take a deep breath-- ssh into the host, run bash -c with a command of screen, which will make a new window. If this window just opened up ls, it would end, and screen would terminate, so we use fons's trick inside the new screen window.

I think that'll work, if that's even what you were trying to do ;)

share|improve this answer
I think the problem I have with screen in this situation, is that I normally load it with exec screen -RR from my .profile. This means that bash -l tries to load screen which throws off the rest of it. it seems I can get around it by removing '-l' in both yours and @fons solutions (yours then leaves me in screen). It's kind of wonky though. – matthew Jul 24 '13 at 15:33

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.