[SOLVED] bash script to work on server

sag2662 · 03-21-2024, 03:48 AM

Hi all,

I am trying to interact with the Terminal server via bash. I wrote a small script to be executed on terminal server, but i have the below error. If I remove EOF, then it atleast the ssh connection estlablished, but doesnot run any commands (enable,config)after that

Code:

shell request failed on channel 0

Can anyone suggest me what is missing

Code:

#!/bin/bash
# SSH connection and command execution
sshpass -f pass_file ssh  -NT -o StrictHostKeyChecking=no username@ip <<EOF
enable
config
exit
EOF

Turbocapitalist · 03-21-2024, 04:12 AM

I would do it with keys instead.

Code:

#!/bin/sh
# SSH connection and command execution
ssh -i ${HOME}/.ssh/ip_ed25519 -NT username@ip 'enable; config;'

For that you'll need a key, and for bonus points you can lock it down in the server's ~/.ssh/authorized_keys by prepending command="config; enable" to the line with the key.

If the two programs on the server, config and enbale, are interactive, then you will need -t instead of -T and -N there.

pan64 · 03-21-2024, 05:01 AM

you might try also something like this:

Code:

cat script | ssh -i .....

https://stackoverflow.com/questions/...remote-machine

Turbocapitalist · 03-21-2024, 05:09 AM

Quote:

Originally Posted by pan64

you might try also something like this:

Code:

cat script | ssh -i .....

That's a good way too, but it would also need to suppress the psuedo-TTY allocation with the -T option:

Code:

cat script | ssh -T -i .....

sag2662 · 03-21-2024, 07:38 AM

Quote:

Originally Posted by Turbocapitalist

I would do it with keys instead.

Code:

#!/bin/sh
# SSH connection and command execution
ssh -i ${HOME}/.ssh/ip_ed25519 -NT username@ip 'enable; config;'

For that you'll need a key, and for bonus points you can lock it down in the server's ~/.ssh/authorized_keys by prepending command="config; enable" to the line with the key.

If the two programs on the server, config and enbale, are interactive, then you will need -t instead of -T and -N there.

The problem is I wanted to check for multiple terminal servers and for each terminal server the public key is different.

sag2662 · 03-21-2024, 07:39 AM

Quote:

Originally Posted by Turbocapitalist

That's a good way too, but it would also need to suppress the psuedo-TTY allocation with the -T option:

Code:

cat script | ssh -T -i .....

I still have the same error

shell request failed on channel 0

Turbocapitalist · 03-21-2024, 07:46 AM

Quote:

Originally Posted by sag2662

The problem is I wanted to check for multiple terminal servers and for each terminal server the public key is different.

The public key only needs to go into ${HOME}/.ssh/known_hosts once and then you are good.

But if you are connecting to multiple remote servers:

Then you can make a bunch of keys and give them predictable names so that they can be globbed:

Code:

for key in ${HOME}/.ssh/server_*_ed25519; do
        ssh -i ${HOME}/.ssh/${key} -NT username@ip 'enable; config;'
done

It would be safer (and probably more convenient) with keys than leaving the passsword lying around and, again, the keys can be locked down on the server end using the command="..." option in ~/.ssh/authorized_keys on the server. See "man sshd" for more details.

Turbocapitalist · 03-21-2024, 07:49 AM

If the two programs on the server, config and enable, are interactive, then you will need -t instead of -T and -N there.

sag2662 · 03-21-2024, 07:53 AM

Quote:

Originally Posted by Turbocapitalist

That's a good way too, but it would also need to suppress the psuedo-TTY allocation with the -T option:

Code:

cat script | ssh -T -i .....

cat test | ssh username@ip 'cat > test'

I have exec request failed on channel 0

Turbocapitalist · 03-21-2024, 07:59 AM

Quote:

Originally Posted by sag2662

cat test | ssh username@ip 'cat > test'

I have exec request failed on channel 0

You might try increasing the verbosity with a -v or three on the client to get a little more information on the client side.

Code:

cat test | ssh username@ip 'cat > test'
cat test | ssh username@ip -v 'cat > test'
cat test | ssh username@ip -v -v 'cat > test'
cat test | ssh username@ip -v -v -v 'cat > test'

If that yields no clues, then it might be time to look at the server logs, if they are available.

NevemTeve · 03-21-2024, 08:07 AM

Has the "Terminal server" got some documentation?

pan64 · 03-21-2024, 08:24 AM

yes, it is most probably a server side issue, need to check the configuration. And the server side logs. Probably you need to start sshd in debug mode.

sag2662 · 03-21-2024, 08:48 AM

Quote:

Originally Posted by pan64

yes, it is most probably a server side issue, need to check the configuration. And the server side logs. Probably you need to start sshd in debug mode.

Atleast it works with /usr/bin/expect commands

Code:

# Spawn SSH connection
spawn ssh -o StrictHostKeyChecking=no $username@$device_ip

expect {
    "password:" {
        send "$password\r"
        exp_continue
    }
    ">" {
        send "enable\r"
        send "config\r"
   }
    "#" {
        exit
    }

michaelk · 03-21-2024, 03:05 PM

Just being curious. With a prompt like ">" and commands like enable or config it does not appear you are logging into a linux server but some type of managed device like a Cisco switch or router which runs its own embedded firmware. Since there isn't a shell it isn't possible to run commands as desired.

metaed · 03-21-2024, 03:28 PM

Quote:

Originally Posted by michaelk

some type of managed device like a Cisco switch or router which runs its own embedded firmware

Yes, it was mentioned that it's a terminal server. In the past, I have sent remote commands to execute on a Cisco switch over a TELNET circuit. For example to backup the configuration:

Code:

(
echo enable                     ; sleep 0.1
echo "$secret"                  ; sleep 0.1
echo terminal length 0          ; sleep 0.1
echo show running-config        ; sleep 30.0
echo show startup-config        ; sleep 30.0
echo quit                       ; sleep 0.1
) | telnet $ip >$out 2>&1

Of course this is a terrible idea nowadays. The enable-secret goes over the wire as plaintext, and somebody is always listening (or that is what you should assume). OP quite understandably wants to do it over an ssh-encrypted circuit.