Amanda-Users

RE: amrecover using invalid ssh options on Solaris?

2007-04-06 22:33:52
Subject: RE: amrecover using invalid ssh options on Solaris?
From: "Lee, Raymond" <Raymond.Lee AT qwest DOT com>
To: "Chris Hoogendyk" <hoogendyk AT bio.umass DOT edu>, "AMANDA users" <amanda-users AT amanda DOT org>
Date: Fri, 6 Apr 2007 14:24:44 -0500

> -----Original Message-----
> From: owner-amanda-users AT amanda DOT org 
> [mailto:owner-amanda-users AT amanda DOT org] On Behalf Of Chris Hoogendyk
> Sent: Friday, April 06, 2007 1:28 PM
> To: AMANDA users
> Subject: amrecover using invalid ssh options on Solaris?
> 
> 
> My amanda 2.5.1p3 installation on Solaris 9 has been doing backups 
> smoothly for several weeks using ssh authentication.
> 
> I can also do amrecover on the backup server, where I have sizeable 
> spool capacity, and then move files from there across the 
> network using scp.
> 
> However, in trying to configure ssh authentication and use 
> amrecover on 
> the clients, I get:
> 
>     pilot:/var/tmp# /usr/local/sbin/amrecover   
>                                    
>     command-line: line 0: Bad configuration option: 
> PreferredAuthentications
>     AMRECOVER Version 2.5.1p3. Contacting server on 
> mormyrid.bio.mor.nsm ...
>     [request failed: error sending REQ: write error to : Broken pipe]
> 
> A google search indicates that the first error line is an error from 
> ssh. The man pages on Solaris 9 ssh have no indication of an option 
> "PreferredAuthentications". Just for comparison, I ducked into an 
> OpenBSD machine that I have and did a man page on ssh. There 
> is has this 
> option. It is OpenSSH_3.9 with OpenSSL 0.9.7d. If I ask for 
> the version 
> on Solaris 9 (which is based on OpenSSH), I get SSH Version 
> Sun_SSH_1.0.1, protocol versions 1.5/2.0.

Chris,

Search for PreferredAuthentications in {amanda_source}/common-src/ssh-security.c

I don't know C, but maybe you can edit that and recompile?  Or maybe the 
authors only intended Amanda to be compatible with OpenSSH.

Ray


> 
> So, it seems that amrecover is opening a connection with SSH and then 
> trying to contact the amanda server on that connection and getting a 
> broken pipe error because the SSH connection attempt failed.
> 
> I have followed the instructions from 
> http://wiki.zmanda.com/index.php/Configuring_SSH_authenticatio
> n, and I 
> have set up the amanda_client.conf on the client with the lines:
> 
>     conf "daily"            # your config name
> 
>     index_server "mormyrid.bio.mor.nsm"     # your amindexd server
>     tape_server  "mormyrid.bio.mor.nsm"     # your amidxtaped server
>     tapedev      "LIB-162A5"                # your tape device
> 
>     #   auth        - authentication scheme to use between server and 
> client.
>     #                 Valid values are "bsd", "krb4", "krb5" 
> and "ssh".
>     #                 Default: [auth "bsd"]
>     auth "ssh"
> 
>     ssh_keys "/.ssh/id_rsa_amrecover"                       # 
> your ssh 
> keys file if you use ssh auth
> 
> 
> So, is this an amanda bug? Is there a workaround or patch? Or have I 
> done something wrong in my setup? If so, what should I be 
> looking for? I 
> don't want to have to run around to all my Solaris 9 servers 
> and install 
> and configure OpenSSH. Not only would it be a lot of work, 
> but it would 
> complicate my configurations. Sun SSH is working just fine in 
> all other 
> respects. Switching to OpenSSH would have a cascade effect. Sun built 
> tcp-wrappers into their system configuration, as well as 
> various other 
> security items, and if I installed OpenSSH, I would also have 
> to install 
> tcp-wrappers and replicate all the security work on all of my servers.
> 
> TIA
> 
> 
> ---------------
> 
> Chris Hoogendyk
> 
> -
>    O__  ---- Systems Administrator
>   c/ /'_ --- Biology & Geology Departments
>  (*) \(*) -- 140 Morrill Science Center
> ~~~~~~~~~~ - University of Massachusetts, Amherst 
> 
> <hoogendyk AT bio.umass DOT edu>
> 
> --------------- 
> 
> Erdös 4
> 
> 
> 


This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attachments.