using "at" and ssh - SSH

This is a discussion on using "at" and ssh - SSH ; I have a script that uses ssh. I'd like to schedule it to run when I'm not logged on, like in the middle of the night. When I log on, I do my "ssh-agent bash" then "ssh-add" followed by my ...

+ Reply to Thread
Results 1 to 11 of 11

Thread: using "at" and ssh

  1. using "at" and ssh

    I have a script that uses ssh. I'd like to schedule it to run
    when I'm not logged on, like in the middle of the night.

    When I log on, I do my "ssh-agent bash" then "ssh-add" followed
    by my passphrase. I can then run my script under "at" with no
    problem -- as long as I remain logged on my putty window.

    But when I set the command to run under at after I've logged off,
    it wants my passphrase again and I get:

    Bad passphrase.
    Permission denied.

    Does anybody know how to make this work, perhaps some other way?

    Thanks.

  2. Re: using "at" and ssh

    >>>>> "RR" == RR writes:

    RR> I have a script that uses ssh. I'd like to schedule it to run
    RR> when I'm not logged on, like in the middle of the night.

    RR> When I log on, I do my "ssh-agent bash" then "ssh-add" followed by
    RR> my passphrase. I can then run my script under "at" with no
    RR> problem -- as long as I remain logged on my putty window.

    RR> But when I set the command to run under at after I've logged off,
    RR> it wants my passphrase again and I get:

    RR> Bad passphrase. Permission denied.

    RR> Does anybody know how to make this work, perhaps some other way?

    http://www.snailbook.com/faq/no-passphrase.auto.html

    --
    Richard Silverman
    res@qoxp.net


  3. Re: using "at" and ssh


    > RR said:
    > I have a script that uses ssh. I'd like to schedule it to run
    > when I'm not logged on, like in the middle of the night.
    > When I log on, I do my "ssh-agent bash" then "ssh-add" followed
    > by my passphrase. I can then run my script under "at" with no
    > problem -- as long as I remain logged on my putty window.
    > But when I set the command to run under at after I've logged off,
    > it wants my passphrase again and I get:
    > Bad passphrase.
    > Permission denied.
    > Does anybody know how to make this work, perhaps some other way?
    > Thanks.



    You are killing the agent when you logoff.

    Use this:
    eval `ssh-agent -s`

    Not this:
    ssh-agent bash






  4. Re: using "at" and ssh

    Cloud Burst wrote:
    > So let's say I do this and come back the next day. My job ran fine,
    > but now there is this ssh-agent running that I can't use for anything,
    > right? According to the ssh-add man page (and I tried) I can't use a
    > new ssh-add against this old ssh-agent. I have to start a new agent.


    You don't have to start a new agent. You can use the old agent if you
    have saved the relevant environment variables in a file so they can be
    read by your new shell. A few lines in my .bash_profile do this, along
    with a check that the agent still exists:

    # Save ssh-agent environment variables in a file
    # so that they can be read by processes not inheriting
    # this environment; e.g., those started by cron.
    # But don't start more than one agent, so check first.
    [ -f $HOME/.ssh-agent ] && . $HOME/.ssh-agent
    if ! ssh-add -l >/dev/null 2>&1
    then
    ssh-agent | head -2 >$HOME/.ssh-agent
    . $HOME/.ssh-agent
    fi

    If the data in $HOME/.ssh-agent is stale (i.e., the corresponding agent
    is dead), ssh-add will return an error and a new agent will be started.

    Scripts (started by cron, for example) just have to read in the
    environment variables to be able to contact the agent, with a line
    like:

    . $HOME/.ssh-agent

    (with perhaps a check for a dead agent as above and suitable error
    handling).

    --
    John Wingate Mathematics is the art which teaches
    johnww@worldpath.net one how not to make calculations.
    --Oscar Chisini

  5. Re: using "at" and ssh


    > > Cloud Burst wrote:
    > > So let's say I do this and come back the next day. My job ran fine,
    > > but now there is this ssh-agent running that I can't use for anything,
    > > right? According to the ssh-add man page (and I tried) I can't use a
    > > new ssh-add against this old ssh-agent. I have to start a new agent.


    > John Wingate wrote:
    > You don't have to start a new agent. You can use the old agent if you
    > have saved the relevant environment variables in a file so they can be
    > read by your new shell. A few lines in my .bash_profile do this, along
    > with a check that the agent still exists:
    >
    > # Save ssh-agent environment variables in a file
    > # so that they can be read by processes not inheriting
    > # this environment; e.g., those started by cron.
    > # But don't start more than one agent, so check first.
    > [ -f $HOME/.ssh-agent ] && . $HOME/.ssh-agent
    > if ! ssh-add -l >/dev/null 2>&1
    > then
    > ssh-agent | head -2 >$HOME/.ssh-agent
    > . $HOME/.ssh-agent
    > fi
    >
    > If the data in $HOME/.ssh-agent is stale (i.e., the corresponding agent
    > is dead), ssh-add will return an error and a new agent will be started.
    > Scripts (started by cron, for example) just have to read in the
    > environment variables to be able to contact the agent, with a line
    > like:
    > . $HOME/.ssh-agent
    > (with perhaps a check for a dead agent as above and suitable error
    > handling).



    Like John said, the clients (ssh,ssh-add) rendezvous with the agent via
    two environment variables: SSH_AGENT_PID and SSH_AUTH_SOCK

    You need to save and restore these two variables via some scheme such
    as the one John provided.






















  6. Re: using "at" and ssh

    On Thu, 29 Dec 2005 22:59:10 -0800, RR wrote:

    > I have a script that uses ssh. I'd like to schedule it to run
    > when I'm not logged on, like in the middle of the night.


    Maybe look at Keychain: http://www.gentoo.org/proj/en/keychain/

    --
    -Menno.


  7. Re: using "at" and ssh

    On Sat, 31 Dec 2005 17:05:25 -0000, John Wingate wrote:

    >Cloud Burst wrote:
    >> So let's say I do this and come back the next day. My job ran fine,
    >> but now there is this ssh-agent running that I can't use for anything,
    >> right? According to the ssh-add man page (and I tried) I can't use a
    >> new ssh-add against this old ssh-agent. I have to start a new agent.

    >
    >You don't have to start a new agent. You can use the old agent if you
    >have saved the relevant environment variables in a file so they can be
    >read by your new shell. A few lines in my .bash_profile do this, along
    >with a check that the agent still exists:
    >
    > # Save ssh-agent environment variables in a file
    > # so that they can be read by processes not inheriting
    > # this environment; e.g., those started by cron.
    > # But don't start more than one agent, so check first.
    > [ -f $HOME/.ssh-agent ] && . $HOME/.ssh-agent
    > if ! ssh-add -l >/dev/null 2>&1
    > then
    > ssh-agent | head -2 >$HOME/.ssh-agent
    > . $HOME/.ssh-agent
    > fi
    >
    >If the data in $HOME/.ssh-agent is stale (i.e., the corresponding agent
    >is dead), ssh-add will return an error and a new agent will be started.
    >
    >Scripts (started by cron, for example) just have to read in the
    >environment variables to be able to contact the agent, with a line
    >like:
    >
    > . $HOME/.ssh-agent
    >
    >(with perhaps a check for a dead agent as above and suitable error
    >handling).


    This is great stuff. Thanks a lot.

    Almost there, but I still have one problem. I can't seem to get what I
    put in the background to work properly. For example, I have a little
    test script called foo that looks like this:

    % cat foo
    ssh myhost ls

    Then if I do this:

    % ./foo > ls.txt

    ....works fine. But:

    % ./foo > ls.txt &

    ....doesn't. It is immediately stopped by bash. I then have to "fg" it
    and press the Enter key. It then runs.

    I tried this with my big script and

    What I REALLY want to do is run my job like this: "nohup mybigjob &" but
    it behaves the same way. It runs fine until it gets to the first command
    that uses ssh. It is then stopped by bash, I have to put in foreground
    and hit the Enter key. It then takes off and the command succeeds, as
    well as all the rest of the commands in the script that use ssh.

    Is there a way around this?

  8. Re: using "at" and ssh


    > Cloud Burst wrote:
    > This is great stuff. Thanks a lot.
    > Almost there, but I still have one problem. I can't seem to get what I
    > put in the background to work properly. For example, I have a little
    > test script called foo that looks like this:
    >
    > % cat foo
    > ssh myhost ls
    >
    > Then if I do this:
    >
    > % ./foo > ls.txt
    >
    > ...works fine. But:
    >
    > % ./foo > ls.txt &
    >
    > ...doesn't. It is immediately stopped by bash. I then have to "fg" it
    > and press the Enter key. It then runs.
    >
    > I tried this with my big script and
    >
    > What I REALLY want to do is run my job like this: "nohup mybigjob &" but
    > it behaves the same way. It runs fine until it gets to the first command
    > that uses ssh. It is then stopped by bash, I have to put in foreground
    > and hit the Enter key. It then takes off and the command succeeds, as
    > well as all the rest of the commands in the script that use ssh.
    >
    > Is there a way around this?



    Try:
    ssh -n myhost ls > ls.txt &

























  9. Re: using "at" and ssh

    Cloud Burst wrote:
    > On Sat, 31 Dec 2005 17:05:25 -0000, John Wingate wrote:
    >> You don't have to start a new agent. You can use the old agent if you
    >> have saved the relevant environment variables in a file so they can be
    >> read by your new shell.
    >> [ example code and accompanying comments snipped for brevity ]


    > This is great stuff. Thanks a lot.


    You're welcome. One thing I forgot to mention is that you want to
    start an agent only for local logins, so shell initialization code like
    I gave should be skipped when logging in from a remote host. (I test
    whether SSH_CLIENT has been set or not.)

    > Almost there, but I still have one problem. I can't seem to get what I
    > put in the background to work properly. For example, I have a little
    > test script called foo that looks like this:
    >
    > % cat foo
    > ssh myhost ls
    >
    > Then if I do this:
    >
    > % ./foo > ls.txt
    >
    > ...works fine. But:
    >
    > % ./foo > ls.txt &
    >
    > ...doesn't. It is immediately stopped by bash. I then have to "fg" it
    > and press the Enter key. It then runs.


    I can't reproduce this behavior. "./foo > ls.txt &" works just fine for me.
    Someone else will have to help with this problem. What version of bash?

    (Is your shell really bash? "% " looks more like a csh prompt, but
    perhaps that's your choice of prompt for bash--or it's just an example
    prompt for posting.)

    --
    John Wingate Mathematics is the art which teaches
    johnww@worldpath.net one how not to make calculations.
    --Oscar Chisini

  10. Re: using "at" and ssh

    On Mon, 2 Jan 2006 09:20:45 +0100 (CET), Anonymous wrote:

    >
    >> Cloud Burst wrote:
    >> This is great stuff. Thanks a lot.
    >> Almost there, but I still have one problem. I can't seem to get what I
    >> put in the background to work properly. For example, I have a little
    >> test script called foo that looks like this:
    >>
    >> % cat foo
    >> ssh myhost ls
    >>
    >> Then if I do this:
    >>
    >> % ./foo > ls.txt
    >>
    >> ...works fine. But:
    >>
    >> % ./foo > ls.txt &
    >>
    >> ...doesn't. It is immediately stopped by bash. I then have to "fg" it
    >> and press the Enter key. It then runs.
    >>
    >> I tried this with my big script and
    >>
    >> What I REALLY want to do is run my job like this: "nohup mybigjob &" but
    >> it behaves the same way. It runs fine until it gets to the first command
    >> that uses ssh. It is then stopped by bash, I have to put in foreground
    >> and hit the Enter key. It then takes off and the command succeeds, as
    >> well as all the rest of the commands in the script that use ssh.
    >>
    >> Is there a way around this?

    >
    >
    >Try:
    > ssh -n myhost ls > ls.txt &


    Yep. Thanks. That did it.

  11. Re: using "at" and ssh

    On Mon, 02 Jan 2006 17:49:47 -0000, John Wingate wrote:

    >Cloud Burst wrote:
    >> On Sat, 31 Dec 2005 17:05:25 -0000, John Wingate wrote:
    >>> You don't have to start a new agent. You can use the old agent if you
    >>> have saved the relevant environment variables in a file so they can be
    >>> read by your new shell.
    >>> [ example code and accompanying comments snipped for brevity ]

    >
    >> This is great stuff. Thanks a lot.

    >
    >You're welcome. One thing I forgot to mention is that you want to
    >start an agent only for local logins, so shell initialization code like
    >I gave should be skipped when logging in from a remote host. (I test
    >whether SSH_CLIENT has been set or not.)
    >
    >> Almost there, but I still have one problem. I can't seem to get what I
    >> put in the background to work properly. For example, I have a little
    >> test script called foo that looks like this:
    >>
    >> % cat foo
    >> ssh myhost ls
    >>
    >> Then if I do this:
    >>
    >> % ./foo > ls.txt
    >>
    >> ...works fine. But:
    >>
    >> % ./foo > ls.txt &
    >>
    >> ...doesn't. It is immediately stopped by bash. I then have to "fg" it
    >> and press the Enter key. It then runs.

    >
    >I can't reproduce this behavior. "./foo > ls.txt &" works just fine for me.
    >Someone else will have to help with this problem. What version of bash?
    >
    >(Is your shell really bash? "% " looks more like a csh prompt, but
    >perhaps that's your choice of prompt for bash--or it's just an example
    >prompt for posting.)


    Right. Next time I'll use "bash>"

    GNU bash, version 2.05b.0(1)-release (x86_64-redhat-linux-gnu)
    Copyright (C) 2002 Free Software Foundation, Inc.

    Looks like "ssh -n" solves my problem.

+ Reply to Thread