4 ms·

what's wrong with expect spawning ssh??

jstimpfle 10y ago
I think expect is often used to have it enter username and password "interactively". But it's easier and more robust to just use the public-key auth facility that is built-in to ssh.
- Karunamon 10y ago
  Not always possible. The problem is that ssh lives in the mythical land of perfect security, where people never need to do unsafe things in order to get their jobs done. Hence keys silently not working without "correct" permissions, passwords not passable on the CLI, inconsistent type-yes-to-override behavior, and other user-hostile design choices. I love openssh, but it's a real pain in the ass sometimes.
  - jstimpfle 10y ago
    I don't have any of these problems. Just don't use passwords non-interactively, but use public key auth. Also, as any sane program, (open)SSH does not ask you to type anything when running non-interactively in a script (more precisely, when no terminal is present).
    - Karunamon 10y ago
      If you don't have any of those problems, you're very lucky. Again, ssh is designed with the assumption that people never have a reason to do unsafe things.
  - seiferteric 10y ago
    there is also sshpass for supplying password, as well as using a languages library like paramiko for python which I believe allows you to supply a password. It would take more than password auth to force me to use expect these days :)
- crististm 10y ago
  This isn't expects' fault. If you did not want to record the password in the script then ssh manually and then continue the script from there (e.g. with 'interact' command)
wyldfire 10y ago
expect scripts in general are brittle IMO. The general design is: "look for this and then that and then this. If at some point you stall along this path for more than X seconds, something must have gone wrong, abort." Well, I maintain that the characters in the stream aren't as good success criterion as the stack of exit codes among the tasks. So if I "ssh remotefoo /tests/the_test.sh" it is the_test.sh's job to return 0 if it succeeded and nonzero otherwise. ssh will return 0 if the remote script returns zero, so I can count on that. But if the host is busy sometimes and the_test.sh takes 91 seconds on a heavily-loaded day but 37-45 seconds normally, I might encode the wrong timeout in my expect script. Things like /etc/issue or /etc/motd or PS1 should have no bearing on my test results. But if someone writes the text "Password:" or "Username:" or some other similar content in there, my expect script might choke on it.
- zwischenzug 10y ago
  Indeed, which is why in ShutIt I used some tricks with the prompt to determine whether a command was finished, and then (optional, but defaulting) checks on exit codes to determine success/failure. It seems to work pretty well, and no need to specify what it expected. It results in code like this: https://github.com/ianmiell/shutit-chef-env/blob/master/shutit_chef_env.py#L83-L88 https://github.com/ianmiell/shutit-chef-env/blob/master/shut... which sets up a chef server.
  - wyldfire 10y ago
    Aside: the bare except clause used here [1] is a bad habit. You should try to avoid it. Python raises things like NameError and TypeError for simple design problems like mistyping variable names. It's extremely rare that you can handle errors like that. Your "except:" would attempt to handle and effectively mask bugs like this. [1] https://github.com/ianmiell/shutit-chef-env/blob/master/shutit_chef_env.py#L56 https://github.com/ianmiell/shutit-chef-env/blob/master/shut...
    - zwischenzug 10y ago
      Thanks for the tip. Laziness is a sin and a virtue.
mypalmike 10y ago
Why would you mix expect with ssh? Most of the time, if you can ssh, you can use an exec channel ("ssh somehost somecommand"), so you shouldn't need to pretend to be typing characters and waiting for prompts.

I think expect is often used to have it enter username and password "interactively". But it's easier and more robust to just use the public-key auth facility that is built-in to ssh.

Karunamon 10y ago
Not always possible. The problem is that ssh lives in the mythical land of perfect security, where people never need to do unsafe things in order to get their jobs done. Hence keys silently not working without "correct" permissions, passwords not passable on the CLI, inconsistent type-yes-to-override behavior, and other user-hostile design choices. I love openssh, but it's a real pain in the ass sometimes.
- jstimpfle 10y ago
  I don't have any of these problems. Just don't use passwords non-interactively, but use public key auth. Also, as any sane program, (open)SSH does not ask you to type anything when running non-interactively in a script (more precisely, when no terminal is present).
  - Karunamon 10y ago
    If you don't have any of those problems, you're very lucky. Again, ssh is designed with the assumption that people never have a reason to do unsafe things.
- seiferteric 10y ago
  there is also sshpass for supplying password, as well as using a languages library like paramiko for python which I believe allows you to supply a password. It would take more than password auth to force me to use expect these days :)
crististm 10y ago
This isn't expects' fault. If you did not want to record the password in the script then ssh manually and then continue the script from there (e.g. with 'interact' command)

wyldfire 10y ago

expect scripts in general are brittle IMO. The general design is: "look for this and then that and then this. If at some point you stall along this path for more than X seconds, something must have gone wrong, abort." Well, I maintain that the characters in the stream aren't as good success criterion as the stack of exit codes among the tasks. So if I "ssh remotefoo /tests/the_test.sh" it is the_test.sh's job to return 0 if it succeeded and nonzero otherwise. ssh will return 0 if the remote script returns zero, so I can count on that. But if the host is busy sometimes and the_test.sh takes 91 seconds on a heavily-loaded day but 37-45 seconds normally, I might encode the wrong timeout in my expect script. Things like /etc/issue or /etc/motd or PS1 should have no bearing on my test results. But if someone writes the text "Password:" or "Username:" or some other similar content in there, my expect script might choke on it.

zwischenzug 10y ago
Indeed, which is why in ShutIt I used some tricks with the prompt to determine whether a command was finished, and then (optional, but defaulting) checks on exit codes to determine success/failure. It seems to work pretty well, and no need to specify what it expected. It results in code like this: https://github.com/ianmiell/shutit-chef-env/blob/master/shutit_chef_env.py#L83-L88 https://github.com/ianmiell/shutit-chef-env/blob/master/shut... which sets up a chef server.
- wyldfire 10y ago
  Aside: the bare except clause used here [1] is a bad habit. You should try to avoid it. Python raises things like NameError and TypeError for simple design problems like mistyping variable names. It's extremely rare that you can handle errors like that. Your "except:" would attempt to handle and effectively mask bugs like this. [1] https://github.com/ianmiell/shutit-chef-env/blob/master/shutit_chef_env.py#L56 https://github.com/ianmiell/shutit-chef-env/blob/master/shut...
  - zwischenzug 10y ago
    Thanks for the tip. Laziness is a sin and a virtue.

mypalmike 10y ago

Why would you mix expect with ssh? Most of the time, if you can ssh, you can use an exec channel ("ssh somehost somecommand"), so you shouldn't need to pretend to be typing characters and waiting for prompts.