expectperl-discuss

RE: [Expectperl-discuss] Executing consecutive commands

[Blackstone, J. D. <jda...@ci...>]

>       The following code is close but how do I continue after 
> logging in with username/password and execute a
>       series of command?
> 
>       If I put qr/$prompt/
> 
>       $exp->expect($timeout,, sub...
>       commands
> 
>       It goes into an endless loop. 

  Don't use exp_continue.  Use a separate $exp->expect for each step.

> 
>       ----------- Start perl code 
>       [ qr/username: /i, sub { my $self = shift;
>       $self->send("$username\n");
>       exp_continue; }],
>       [ qr/password: /i, sub { my $self = shift;
>       $self->send("$password\n");
>       exp_continue; }],
>       $shell_prompt);
>       ----------- Start perl code

$exp->expect(qr/username: /i);
$exp->send("$username\r");
$exp->expect(qr/password: /i);
$exp->send("$password\r");
$exp->expect("$shell_prompt");
...

  This should work, unless there's a particular reason you wanted to use one
expect statement for them all (perhaps the username and/or password prompts
are optional?).

jdb

Re: [Expectperl-discuss] Executing consecutive commands

[<RGi...@a1...>]

> I have a stupid question:
> 
>      I want to do the following but in perl using the expect perl 
> module.
>      ----------- Start expect code
>      spawn ssh -l $user $argv
>      expect "${user}@${argv}'s password:"
>      send "$password\r"

From the Expect manpage:

"I want to automate password entry for su/ssh/scp/rsh/...

    You shouldn't use Expect for this. Putting passwords, especially 
root passwords, into scripts in clear text can mean severe security 
problems.  I strongly recommend using other means. For 'su', consider 
switching to 'sudo', which gives you root access on a per-command and 
per-user basis without the need to enter passwords. 'ssh'/'scp' can be 
set up with RSA authentication without passwords. 'rsh' can use 
the .rhost mechanism, but I'd strongly suggest to switch to 'ssh'; to 
mention 'rsh' and 'security' in the same sentence makes an oxymoron.

    It will work for 'telnet', though, and there are valid uses for it, 
but you still might want to consider using 'ssh', as keeping cleartext  
passwords around is very insecure.

Source Examples
How to automate login

  my $exp = Expect->spawn("telnet localhost")
    or die "Cannot spawn telnet: $!\n";;
  my $spawn_ok;
  $exp->expect($timeout,
               [
                qr'login: $',
                sub {
                  $spawn_ok = 1;
                  my $fh = shift;
                  $fh->send("$username\n");
                  exp_continue;
                }
               ],
               [
                'Password: $',
                sub {
                  my $fh = shift;
                  print $fh "$password\n";
                  exp_continue;
                }
                ],
               [
                eof =>
                sub {
                  if ($spawn_ok) {
                    die "ERROR: premature EOF in login.\n";
                  } else {
                    die "ERROR: could not spawn telnet.\n";
                  }
                }
               ],
               [
                timeout =>
                sub {
                  die "No login.\n";
                }
               ],
               '-re', qr'[#>:] $', #' wait for shell prompt, then exit
              );


Hope this helps,

Roland
--
RGi...@cp...

Re: [Expectperl-discuss] Executing consecutive commands

[Austin S. <te...@of...>]

On Thu, Apr 18, 2002 at 11:56:57AM +0200, RGi...@a1... wrote:
>     You shouldn't use Expect for this. Putting passwords, especially 
> root passwords, into scripts in clear text can mean severe security 
> problems.  I strongly recommend using other means. For 'su', consider 
> switching to 'sudo', which gives you root access on a per-command and 
> per-user basis without the need to enter passwords. 'ssh'/'scp' can be 
> set up with RSA authentication without passwords. 'rsh' can use 
> the .rhost mechanism, but I'd strongly suggest to switch to 'ssh'; to 
> mention 'rsh' and 'security' in the same sentence makes an oxymoron.
> 
	Something I don't quite understand about this is that RSA
authentication only seems to check to see if you have a matching key and
password. That is to say, it doesn't seem to check to make sure the host you
are coming from is the one that matches your key. If you set up RSA w/ no
password, then all someone would need to do is copy your key to their machine
to gain access. This doesn't seem especially secure to me vs. any other
method, especially .shosts. Maybe this is just local configuration, but it
seems to be the default. Is there some way to turn on host checking that I
missed?
	The one thing about keeping cleartext passwords around that's good
is that the security implications are obvious. If you keep them in a 
file accessible only by yourself then someone would have to be either you
or root to gain access. If you combine that with tcp wrappers at the remote
end I'd say it's reasonably secure - though again probably not as good as
.shosts, which _does_ seem to check vs. ssh's known_hosts file to make sure
you're coming from the correct host.

	Austin

Re: [Expectperl-discuss] Executing consecutive commands

[<RGi...@a1...>]

> 	Something I don't quite understand about this is that RSA
> authentication only seems to check to see if you have a matching 
> key and password. That is to say, it doesn't seem to check to
> make sure the host you are coming from is the one that matches
> your key. If you set up RSA w/ no password, then all someone
> would need to do is copy your key to their machine to gain
> access. This doesn't seem especially secure to me vs. any 
> other method, especially .shosts.

Yes, and that is why the ssh docs disapprove keys without passwords and 
recommend using ssh-agent.  Unfortunately automating things means you 
have to compromize.

> Maybe this is just local 
> configuration, but it seems to be the default. Is there some
> way to turn on host checking that I missed?

Yes, you can specify 'from=<hostnamepatterns>' in authorized_keys to 
limit accessibility to the account.  This isn't entirely secure either, 
but to circumvent it, the attacker must also compromize DNS and/or IP 
routing.  Note that even a client host key check doesn't mean improved 
security if the client system is compromized.

> The one thing about keeping cleartext passwords around that's good
> is that the security implications are obvious.

Unfortunately not to everyone... :-(

I concurr that there is no principal difference in security between a 
file with cleartext passwords and a key file with non-password-
protected keys from a security point of view.  But using the second one 
is much simpler, you may even not need Expect for it, normal ssh calls 
are often enough!  And reduced complexity benefits everyone.

Roland
--
RGi...@cp...