how to automate telnet thro' expect cmd - Linux

This is a discussion on how to automate telnet thro' expect cmd - Linux ; sir, I want to automate my telnet connection(instead of typing repeated username & password) I suppose i can write expect script #!/usr/bin/expect eval spawn telnet ip set timeout 20 expect login: send "username\r" expect password: send "password\r" sleep 2 interact ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: how to automate telnet thro' expect cmd

  1. how to automate telnet thro' expect cmd

    sir,
    I want to automate my telnet connection(instead of typing
    repeated username & password)
    I suppose i can write expect script

    #!/usr/bin/expect

    eval spawn telnet ip
    set timeout 20
    expect login:
    send "username\r"
    expect password:
    send "password\r"
    sleep 2
    interact

    when i 'm running sh scriptname i 'm getting the error "command
    spawn not found"
    i removed the spawn
    even the system says

    telnet hostname
    login:
    (but it didn't proceeds with username & passwd which i send in the
    script
    help me

  2. Re: how to automate telnet thro' expect cmd

    In comp.os.linux.misc karthikeyan wrote:
    > I want to automate my telnet connection(instead of typing


    NO, you want to turn it off. Your password is by now all over the net.
    Telnet sends it in the clear.

    > repeated username & password)
    > I suppose i can write expect script


    No you can't. You can use something other than telnet. ssh, for
    example.

    Welcome to the 21st century.

    Peter

  3. Re: how to automate telnet thro' expect cmd

    "Peter T. Breuer" wrote in message
    news:214bgb.7in.ln@news.it.uc3m.es...
    > In comp.os.linux.misc karthikeyan wrote:
    > > I want to automate my telnet connection(instead of typing

    >
    > NO, you want to turn it off. Your password is by now all over the net.
    > Telnet sends it in the clear.
    >
    > > repeated username & password)
    > > I suppose i can write expect script

    >
    > No you can't. You can use something other than telnet. ssh, for
    > example.
    >
    > Welcome to the 21st century.
    >
    > Peter


    Please! This kind of reactionary posting makes me ill. Sure, it's a bad
    idea to use telnet because the passwords are passed in the clear. We all
    agree on that. But what's the point in implying that an obvious neophyte is
    a net.idiot? The original poster is not stupid, just new, and I don't see
    any benefit in making him feel bad. In fact, postings like this one tend to
    make people less likely to come to Usenet for answers, which, in the end
    could hurt them more. I think maybe a gentler tone in suggesting a more
    secure remote login paradigm might be in order here.

    And, for the record, the original poster's password is likely not "by now
    all over the net" any more than his password might be if he used it in an
    unprotected http authentication exchange (yes, Virginia, the vast number of
    authenticated http sites do not use SSL). The number of tools available to
    the average script kiddie to break Linux security (or any other OS security,
    ftm) are simply too numerous to make random or directed password sniffing
    the major concern of most Linux users. Other than someone sniffing your
    password from your local segment (shared headend on a Cable conn, or perhaps
    an improperly configured DSLAM for DSL), the danger in sniffed passwords is
    relatively low from a home location.

    If you're at a University, the vast majority of which are basically
    unregulated public networks, then all bets are off, and people *are* likely
    to try and grab your password and use it just because they can. Or, if you
    are at work, and building a box for your employer, then you have sensitive
    data at risk. In either of those cases, I definitely suggest to the
    original poster basically the same remedies... First, change your
    password - immediately. Second, turn off FTP, rsh, and telnet, and turn ON
    SSH. You can then use PuTTY and WinSCP to go from your Win box to the Linux
    box, or you can just user 'ssh' and 'scp' if you are connecting from another
    Unix/Linux box. These measures are indeed extremely effective at preserving
    password privacy.

    Of course, if you *own* the Linux box, you can do what you want... If you
    want to be so wide open as to even have no passwords, then that's your
    prerogative. The security advice you find here, though generally good, is
    merely suggestion rather than requirement. It's your environment... Have a
    good time with it, and learn all you can.

    Best,

    Mark Cecil


    --
    -= Mark Justin Cecil == New Orleans, LA == mjcecil@bellsouth.net =-
    -= http://noml.dyndns.org/mark.html =-
    -= UNIX/Storage Architecture, Implementation, and Administration =-

    "The truth is the truth, no matter what you *believe*"





  4. Re: how to automate telnet thro' expect cmd

    In comp.os.linux.help Mark Cecil wrote:
    > "Peter T. Breuer" wrote in message news:214bgb.7in.ln@news.it.uc3m.es...
    >> In comp.os.linux.misc karthikeyan wrote:
    >> > I want to automate my telnet connection(instead of typing

    >>
    >> NO, you want to turn it off. Your password is by now all over the net.
    >> Telnet sends it in the clear.
    >>
    >> > repeated username & password)
    >> > I suppose i can write expect script

    >>
    >> No you can't. You can use something other than telnet. ssh, for
    >> example.
    >>
    >> Welcome to the 21st century.


    > Please! This kind of reactionary posting makes me ill. Sure, it's a bad
    > idea to use telnet because the passwords are passed in the clear. We all
    > agree on that. But what's the point in implying that an obvious neophyte is
    > a net.idiot?


    Because he obviously is. If he weren't, he would say "I know that using
    telnet is a bad thing because it sends my password over the net for all
    to read, but I have a private net behind a firewall on which I want to
    do local telnet to a linux server, and script the session. Is expect
    the right thing for that"?

    Even windows people can know something about the net and telnet in
    particular!

    > The original poster is not stupid, just new, and I don't see


    He is! Maybe also new.

    Let's rephrase his question: "I usually get past the guards to get back
    into my military camp by shouting the password at them through a
    loudhailer from across the street, but now I'd like a tape recorder to
    do the job instead, so I can relax".

    > any benefit in making him feel bad. In fact, postings like this one tend to


    There's plenty of benefit. He will smarten up in order to stop people
    being able to make him feel bad.

    > make people less likely to come to Usenet for answers, which, in the end
    > could hurt them more. I think maybe a gentler tone in suggesting a more
    > secure remote login paradigm might be in order here.


    > And, for the record, the original poster's password is likely not "by now
    > all over the net" any more than his password might be if he used it in an
    > unprotected http authentication exchange (yes, Virginia, the vast number of
    > authenticated http sites do not use SSL). The number of tools available to
    > the average script kiddie to break Linux security (or any other OS security,
    > ftm) are simply too numerous to make random or directed password sniffing
    > the major concern of most Linux users. Other than someone sniffing your


    Oh - in that case you'd like to try using pop3 across the internet for
    5 mins? Let's count the number of login attempts that follow, shall we!
    (I did this once as an experiment - I tried it from cambridge UK to
    spain, and 10 minutes later the logs were full of attempted logins! My
    experiment was intended to gather data to persuade the other profs to
    stop doing just that when they were away!).

    > password from your local segment (shared headend on a Cable conn, or perhaps
    > an improperly configured DSLAM for DSL), the danger in sniffed passwords is
    > relatively low from a home location.


    It's relatively high in any kind of shared environment. As an example,
    when I gave my twice-yearly internet security talk at $UK_UNI 3 weeks
    ago, I sniffed the local net for broadcast NIS maps and used "john" to
    decrypt the passwords (about a dozen cracked within five minutes), then
    logged in as said users to the winNT switched network, which was using the
    same passwords.

    > If you're at a University, the vast majority of which are basically
    > unregulated public networks, then all bets are off, and people *are* likely


    Yep. But "unregulated public network" includes cybercafes and just
    about anywhere these days. Let's not mention how I called home from the
    sidewalk in Nice, france, the other day, shall I.

    > to try and grab your password and use it just because they can. Or, if you
    > are at work, and building a box for your employer, then you have sensitive
    > data at risk. In either of those cases, I definitely suggest to the
    > original poster basically the same remedies... First, change your
    > password - immediately. Second, turn off FTP, rsh, and telnet, and turn ON
    > SSH. You can then use PuTTY and WinSCP to go from your Win box to the Linux


    I think he's running lin to lin, surely? Or is he scripting at server
    side? What?

    > box, or you can just user 'ssh' and 'scp' if you are connecting from another
    > Unix/Linux box. These measures are indeed extremely effective at preserving
    > password privacy.


    > Of course, if you *own* the Linux box, you can do what you want... If you
    > want to be so wide open as to even have no passwords, then that's your
    > prerogative. The security advice you find here, though generally good, is
    > merely suggestion rather than requirement. It's your environment... Have a
    > good time with it, and learn all you can.


    Well, we agree. You just don't like me making him feel as though he
    know nothing and is from Barcelona.

    Peter

  5. Re: how to automate telnet thro' expect cmd

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    time to step up. try using ssh as opposed to telnet. works basically
    the same but its not cleartext.

    I am not familiar with expect, what is that?

    ssh can use a certificate, so it will not need to use any password or
    username. That is what you want to do. I use it daily.

    man ssh
    man ssh-keygen

    You probably need some lessons in scripts and sub-shells too. You need
    to make sure the commands you issue are all within the context of the
    sub-shell you just initiated with the ssh command.

    maybe like

    ssh myhost(
    ~ command1;
    ~ command2;
    )

    I dont know if this is right or not. I just bought a bash book and I
    left it at home today. maybe you can 'man bash' to figure out how to do
    this.


    CL

    karthikeyan wrote:
    | sir,
    | I want to automate my telnet connection(instead of typing
    | repeated username & password)
    | I suppose i can write expect script
    |
    | #!/usr/bin/expect
    |
    | eval spawn telnet ip
    | set timeout 20
    | expect login:
    | send "username\r"
    | expect password:
    | send "password\r"
    | sleep 2
    | interact
    |
    | when i 'm running sh scriptname i 'm getting the error "command
    | spawn not found"
    | i removed the spawn
    | even the system says
    |
    | telnet hostname
    | login:
    | (but it didn't proceeds with username & passwd which i send in the
    | script
    | help me


    - --
    Respectfully,


    CL Gilbert

    "Verily, verily, I say unto you, He that entereth not by the door() into
    the sheepfold{}, but climbeth up some other *way, the same is a thief
    and a robber." John 10:1

    GnuPG Key Fingerprint:
    82A6 8893 C2A1 F64E A9AD 19AE 55B2 4CD7 80D2 0A2D

    For a free Java interface to Freechess.org see
    http://www.rigidsoftware.com/Chess/chess.html
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.2 (GNU/Linux)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iD8DBQE/KVNRVbJM14DSCi0RAhzSAJ4olRqjmmxkwz8e8icPskeUaXxOzg CdE7GT
    LyI5b71w8ZeAGOKlCsiAHAE=
    =9puf
    -----END PGP SIGNATURE-----


  6. SOT: Re: how to automate telnet thro' expect cmd


    "Peter T. Breuer" wrote in message
    news:kicbgb.8fj.ln@news.it.uc3m.es...
    | In comp.os.linux.help Mark Cecil wrote:
    | > "Peter T. Breuer" wrote in message
    news:214bgb.7in.ln@news.it.uc3m.es...
    | >> In comp.os.linux.misc karthikeyan wrote:
    | >> > I want to automate my telnet connection(instead of typing
    | >>
    | >> NO, you want to turn it off. Your password is by now all over the net.
    | >> Telnet sends it in the clear.
    | >>
    | >> > repeated username & password)
    | >> > I suppose i can write expect script
    | >>
    | >> No you can't. You can use something other than telnet. ssh, for
    | >> example.
    | >>
    | >> Welcome to the 21st century.
    |
    | > Please! This kind of reactionary posting makes me ill. Sure, it's a bad
    | > idea to use telnet because the passwords are passed in the clear. We
    all
    | > agree on that. But what's the point in implying that an obvious
    neophyte is
    | > a net.idiot?
    |
    | Because he obviously is. If he weren't, he would say "I know that using
    | telnet is a bad thing because it sends my password over the net for all
    | to read, but I have a private net behind a firewall on which I want to
    | do local telnet to a linux server, and script the session. Is expect
    | the right thing for that"?
    |
    | Even windows people can know something about the net and telnet in
    | particular!
    |
    | > The original poster is not stupid, just new, and I don't see
    |
    | He is! Maybe also new.
    |
    | Let's rephrase his question: "I usually get past the guards to get back
    | into my military camp by shouting the password at them through a
    | loudhailer from across the street, but now I'd like a tape recorder to
    | do the job instead, so I can relax".
    |
    | > any benefit in making him feel bad. In fact, postings like this one
    tend to
    |
    | There's plenty of benefit. He will smarten up in order to stop people
    | being able to make him feel bad.
    |
    | > make people less likely to come to Usenet for answers, which, in the end
    | > could hurt them more. I think maybe a gentler tone in suggesting a more
    | > secure remote login paradigm might be in order here.
    |
    | > And, for the record, the original poster's password is likely not "by
    now
    | > all over the net" any more than his password might be if he used it in
    an
    | > unprotected http authentication exchange (yes, Virginia, the vast number
    of
    | > authenticated http sites do not use SSL). The number of tools available
    to
    | > the average script kiddie to break Linux security (or any other OS
    security,
    | > ftm) are simply too numerous to make random or directed password
    sniffing
    | > the major concern of most Linux users. Other than someone sniffing your
    |
    | Oh - in that case you'd like to try using pop3 across the internet for
    | 5 mins? Let's count the number of login attempts that follow, shall we!
    | (I did this once as an experiment - I tried it from cambridge UK to
    | spain, and 10 minutes later the logs were full of attempted logins! My
    | experiment was intended to gather data to persuade the other profs to
    | stop doing just that when they were away!).
    |
    | > password from your local segment (shared headend on a Cable conn, or
    perhaps
    | > an improperly configured DSLAM for DSL), the danger in sniffed passwords
    is
    | > relatively low from a home location.
    |
    | It's relatively high in any kind of shared environment. As an example,
    | when I gave my twice-yearly internet security talk at $UK_UNI 3 weeks
    | ago, I sniffed the local net for broadcast NIS maps and used "john" to
    | decrypt the passwords (about a dozen cracked within five minutes), then
    | logged in as said users to the winNT switched network, which was using the
    | same passwords.
    |
    | > If you're at a University, the vast majority of which are basically
    | > unregulated public networks, then all bets are off, and people *are*
    likely
    |
    | Yep. But "unregulated public network" includes cybercafes and just
    | about anywhere these days. Let's not mention how I called home from the
    | sidewalk in Nice, france, the other day, shall I.
    |
    | > to try and grab your password and use it just because they can. Or, if
    you
    | > are at work, and building a box for your employer, then you have
    sensitive
    | > data at risk. In either of those cases, I definitely suggest to the
    | > original poster basically the same remedies... First, change your
    | > password - immediately. Second, turn off FTP, rsh, and telnet, and turn
    ON
    | > SSH. You can then use PuTTY and WinSCP to go from your Win box to the
    Linux
    |
    | I think he's running lin to lin, surely? Or is he scripting at server
    | side? What?
    |
    | > box, or you can just user 'ssh' and 'scp' if you are connecting from
    another
    | > Unix/Linux box. These measures are indeed extremely effective at
    preserving
    | > password privacy.
    |
    | > Of course, if you *own* the Linux box, you can do what you want... If
    you
    | > want to be so wide open as to even have no passwords, then that's your
    | > prerogative. The security advice you find here, though generally good,
    is
    | > merely suggestion rather than requirement. It's your environment...
    Have a
    | > good time with it, and learn all you can.
    |
    | Well, we agree. You just don't like me making him feel as though he
    | know nothing and is from Barcelona.
    |
    | Peter

    Pete - man...

    Gotta lower the caffeine dosage. Slamming people is counterproductive.
    It also takes less words to provide a recommendation than a tirade plus
    solution.

    ken k



+ Reply to Thread