2

How to create ssh session by ssh foo@bar except not any color format? The only require is the setting should be declared at the ssh command and can't be setting at config file.

As an aside, the reason is I want get the ssh shell result to a Scala program, git repos more detail if you interested. So, the color codes, such as[03m(maybe others), should be removed. I can't expect remote host make some setting and let it no color.

UPDATE

  1. about JSch SSH library, there is some setting to explain:

    1. setPtyType("dumb"), the parameter dumb setting the session with dumb emulation terminal similar with Linux, VT100 etc. The dumb emulation terminal is not any colors codes in result. Use echo $TERM will print dumb after setting this property.
    2. setPty(bool enable) default is false but if I explicit setting setPty(false) the result will be break. Unfortunately I haven't find a API to get the pty values at runtime and the library is lack of document even though it is Java de-facto standard SSH library.

  2. why I want use ssh in a ssh?

    1. This feature is need because some key file maybe on remote host.So, I need login the remote host first and then login another host.
    2. login a terminal and use ssh connect to another host is a normal operation.

  3. What's the Scala library output if it has some color codes?
    steps:

    • use JSch create a ssh session connection.
    • use ls
    • connect to new shell
    • use cd /var on the new shell
    • use ls on the new shell.

//use `JSch` create a ssh session connection. 
val shell = new Shell(Auth("hostname", "username", 22, "pwd"))
//use `ls` 
shell.exc("ls")

//connect to new shell   
val newShell = shell.newShell(Auth("xxx.xxx.xxx.xxx", "root", 22, "pwd")).right.get

//use `cd /var` on the new shell  
newShell.exc("cd /var")
//use `ls` on the new shell.
newShell.exc("ls")

newShell.exit()

shell.disconnect()

The command shell.exc("ls") output perfectly because I'm use dumb property to JSch.setPtyType(). It not color codes print.

The problem of the color codes occurred at newShell.exc("ls"), it prints:

[0m[01;34mbackups[0m  [01;34mcache[0m  [01;34mlib[0m  [01;34mlocal[0m  [01;36mlock[0m  [01;34mlog[0m  [01;34mmail[0m  [01;34mopt[0m  [01;36mrun[0m  [01;34mspool[0m  [30;42mtmp[0m

Obviously, it contains some color codes. val newShell is generated by a bare command ssh -t -o StrictHostKeyChecking=no foo@bar, so it different with JSch ways.

Currently, I just want dispose the color codes and keep the response information only contains text:

backups  cache  lib  local  lock  log  mail  opt  run  spool  tmp

Hope it will be clear the question. Thanks again.

UPDATE again

Sorry for my two mistake.

  1. TERM=dumb is needn't at all because JSch has setting dumb and new ssh will fooling it.
  2. setPty(true)(or -T parameter) is affect, my test was fail because of another problem that the MAGIC_SPLIT constants should be start/end with \n rather then \r\n in this mode.

What's the changes should I do?

Use setPty(true) for all message protocol, which contains JSch and ssh with -T parameter, rather then dumb because it is more clear response.

What's the problem left?

Some remote host will response a error message stdin: is not a tty after success login the remote host that is matter because of echo $? will be fail. But it is off topic already.

About this topic

Back to the question how to use ssh session with no color formatting?, the answer is use -T parameter for ssh.

And finally, thanks a lot for @sourcejedi's patience.

Improve this question

1 Answer 1

Reset to default
3

You just do it.

Local programs whose output is piped to another program, are expected to detect that they are not connected to any terminal, so they can't use any color codes (which vary between terminals, hence the TERM environment variable).

And when the local program ssh is piped to another program, and you do not pass the options -tt, it suppresses allocation of a "pseudo-terminal" and uses pipes instead. See also man ssh.

If your code was allocating a "pseudo-terminal" instead of using a pipe to capture the output, you would should notice that fact. In most contexts the code required is more obscure and longer than if you used a pipe; most times you don't need (or, as you say, want) the extra features of a PTY.

EXCEPT I think your question is wrong (in the UPDATE part)

Suppose you're actually not running ssh, and instead running sshpass -p '${auth.password}' ssh...

sshpass, as per it's man page, is running ssh "in a dedicated TTY, fooling it into thinking it is getting the password from an interactive user" (yep, it's another PTY).

In that case, you would need to disable the normal terminal behaviour again for the inner SSH connection. I.e. using ssh -T (not ssh -t as in one of the code commits!).

I think prefixing with TERM=dumb does also achieve a very similar effect. It's a bit of a work-around. ssh -T avoids the need to mess around with TERM. But I tested TERM=dumb sshpass sh -c 'echo $TERM' on my computer, it seems to pass through OK, and maybe it feels simpler to you.

Next question: Why is your testing telling you this is necessary, when your code is also already working to set TERM=dumb, before you launch the (inner) ssh command? You'd expect the ssh to have inherited TERM=dumb already. Look at the code for Jsch. I think your setPtyType("dumb") won't have any effect, for the reason that you don't have any call to setPty(true).

My understanding is contradicted by your assertion that setPty(false) "breaks", but you don't say how.

Improve this answer
9
  • Do you means I should use a pipe, so ssh foo@bar is enough? But it has color codes. Commented Aug 19, 2017 at 7:58
  • hi, with -T parameter, the output is pure text, maybe it close to my need.But why the session can't find ll command? Commented Aug 19, 2017 at 8:37
  • 1) you're being unhelpfully vague, you need to provide an example of a command that uses color codes that you don't want to. For all you were telling us, it could be a specific command that is already reported as behaving badly. Commented Aug 19, 2017 at 9:54
  • 2) Why are you linking to code that uses an SSH library, connects to the remote host, and then runs a second ssh client on the remote host, which connects to the same remote host? It's clearly using the Auth details twice. Why are you referring to code that does this, it can only cause us confusion as to which instance of the ssh client you need to change settings on. 3) the ll thing is a separate question, please ask a new one providing all relevant details Commented Aug 19, 2017 at 9:54
  • Hi, I'm sorry not put enough detail information at first.The deep implement method of the library is append at UPDATE, hope it will be clearer. Commented Aug 19, 2017 at 12:49

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.