<HTML>
<span style="font-weight: bold;">On Fri 03/14/08 12:36 PM , Troy Arnold troy@zenux.net sent:<br>
</span><blockquote style="border-left: 2px solid rgb(245, 245, 245); margin-left: 5px; margin-right: 0px; padding-left: 5px; padding-right: 0px;">On Fri, Mar 14, 2008 at 12:14:18PM -0700, <a href="javascript:top.opencompose('gandalf@sonic.net','','','')">gandalf@sonic.net</a> wrote:
<br>

<span style="color: red;">&gt;  I'm getting confused here. So I thought I'd check in here for a
</span><br>

<span style="color: red;">&gt; second or third opinion. 
</span><br>

<span style="color: red;">&gt;  I have a perl process that logs onto an account on a server across
</span><br>

<span style="color: red;">&gt; town via ssh and auth keys. It first uses sftp to transfer a couple
</span><br>

<span style="color: red;">&gt; files and then it sends a single command via ssh to process those
</span><br>

<span style="color: red;">&gt; files. It works pretty well.
</span><br>

<span style="color: red;">&gt;  Today our main DSL line started experiencing problems, so I
</span><br>

<span style="color: red;">&gt; reconfigured the routers to use our backup Broadlink connection while
</span><br>

<span style="color: red;">&gt; Sonic and AT&amp;T figure out what's going on (looks like it may be a line
</span><br>

<span style="color: red;">&gt; fault).
</span><br>

<span style="color: red;">&gt;  In the meantime this little process has broken down and I'm getting
</span><br>

<span style="color: red;">&gt; regular error messages of it's failure. I tried going in to the
</span><br>

<span style="color: red;">&gt; authorized_keys on the remote server and coping the entry and
</span><br>

<span style="color: red;">&gt; assigning it the secondary ip address, but this doesn't seem to work.
</span><br>

<span style="color: red;">&gt; 
</span><br>

<span style="color: red;">&gt;  Anyone have any suggestions?
</span><br>


<br>

Difficult to say without a specific error message.  I'd try running the
<br>

commands that the script does by hand and see where it pukes.  It may be
<br>

that it's failing because one side doesn't have the host key for the IP
<br>

address of your broadlink account.  You'll probably have to either remove
<br>

an entry in .ssh/known_hosts or add a new one (by logging in successfully
<br>

and saying, 'Yes' when it asks to store the host key).
<br>


<br>

-t
<br>


<br>


<br>

Thank you very much. Turns out to be completely my fault. I managed to reconfigure both our main router and our wireless router to use xxx.xxx.xxx.173 as their address. I'd imagine that caused some weird router pit fighting. I started debugging the specific commands and used ssh with a -v and found that the client server was identifying itself as xxx.xxx.xxx.173 where I had configured it to accept calls form xxx.xxx.xxx.172 this turned out to be the whole issue. I re-configured one of the routers to 172 and patched up the mess I had made of the one autorized_keys file and voilla it works. <br>
<br>
The thing I don't like about linux is that I tend to forget the stuff that I don't do every day (like auth key creation and use). <br>
<br>
Looks like I don't even have to specify the accepted address, but it is better to do so in a case like this. I see that on some of my other servers I don't have the from="xxx.xxx.xxx.xxx" part.<br>

</blockquote><BR></HTML>