Re: [Fab-user] Loading system known_hosts file

[Ashby, Jason (IMS)]

That agrees with what I see on my end as well, and your info filled in a few 
gaps for me.  I don't see any obvious way to set the preferred auth scheme in 
Paramiko.

Our environment is all hostbased ssh, so we don't mess with user keys.  All 
hosts are internal, behind a firewall.  I agree that publickey-based auth is 
more secure though.

When I mentioned "key" I was referring to the host key as found in 
/etc/ssh/*.pub.   I set up our environment similar to the instructions in this 
tutorial: http://cert.uni-stuttgart.de/doc/ssh-host-based.html  .  So we have 
hostbased set up as the preferred auth method in our environment, so I expect 
that hostbased would be selected first when ssh-ing from one server to another.

With that said, I decided its best to run fab via sudo for an audit trail, so 
I'll have to pass fabric my sudo password anyhow.

-----Original Message-----
From: address@hidden [mailto:address@hidden On Behalf Of Jeff Forcier
Sent: Thursday, July 05, 2012 12:22 AM
To: Ashby, Jason (IMS)
Cc: address@hidden
Subject: Re: [Fab-user] Loading system known_hosts file

On Thu, Jun 28, 2012 at 6:47 AM, Ashby, Jason (IMS) <address@hidden> wrote:
> Thanks for the reply Jeff.  Running a debug on the sshd server-side was very 
> helpful.
>
> I can see that when I connect with the ssh client from my shell, the client 
> requests a connection method of 'none' and then 'hostbased'.     Fabric (or 
> Paramiko) seems to request publickey right off the bat.
>
> Is there any way I can specify hostbased as the preferred connection method?  
> Is it possible to set Paramiko settings in my fabfile?

I don't think Paramiko supports hostbased, though it's not originally
my lib so I could be wrong. Certainly Fabric isn't telling it to be
key-based besides giving it a key (i.e. there's no obvious "list of
auth schemes to try" setting in client.connect()).

Without knowing more about your environment I'd say its use of
hostbased is a fluke / red herring, given you originally asked about
using a key (which would be pubkey based auth, not hostbased.)
Certainly key-based auth is more common and (probably) more secure :)

Furthermore, the hostbased auth is triggering before it's even trying
the key, so I'd bet at least a few cents  (yea...I don't gamble) that
the key setup may be broken overall and not just for Fabric.

Assuming you do care about getting the key working: notice that in
your failed debug log output, the remote sshd is looking in
/root/.ssh/authorized_keys2 -- is the public key for your private key
in there?

Alternately, update your sshd config to disable hostbased auth, and
try via 'ssh' + that key, see how that looks on both ends, might give
a clue.

Best,
Jeff


>
>
> Successful login................
>
> address@hidden:~> ssh -t -i /etc/ssh/ssh_host_rsa_key apple uname -s
>
> address@hidden:~> /usr/sbin/sshd -d
> ...snip...
> debug1: userauth-request for user root service ssh-connection method none
> debug1: attempt 0 failures 0
> debug1: PAM: initializing for "root"
> debug1: userauth-request for user root service ssh-connection method hostbased
> debug1: attempt 1 failures 0
> debug1: userauth_hostbased: cuser root chost mainhost. pkalg ssh-dss slen 55
> debug1: PAM: setting PAM_RHOST to "peach"
> debug1: PAM: setting PAM_TTY to "ssh"
> debug1: temporarily_use_uid: 0/0 (e=0/0)
> debug1: restore_uid: 0/0
> debug1: temporarily_use_uid: 0/0 (e=0/0)
> debug1: fd 4 clearing O_NONBLOCK
> debug1: restore_uid: 0/0
> Failed hostbased for root from 172.x.x.x port 54623 ssh2
> debug1: userauth-request for user root service ssh-connection method hostbased
> debug1: attempt 2 failures 1
> debug1: userauth_hostbased: cuser root chost peach. pkalg ssh-rsa slen 271
> debug1: temporarily_use_uid: 0/0 (e=0/0)
> debug1: restore_uid: 0/0
> debug1: temporarily_use_uid: 0/0 (e=0/0)
> debug1: fd 4 clearing O_NONBLOCK
> debug1: restore_uid: 0/0
> debug1: ssh_rsa_verify: signature correct
> debug1: do_pam_account: called
> Accepted hostbased for root from 172.x.x.x port 54623 ssh2
>
>
> Unsuccessful login via Fabric................
>
> address@hidden:~ > fab test
>
> address@hidden:~> /usr/sbin/sshd -d
> ...snip...
> debug1: userauth-request for user root service ssh-connection method publickey
> debug1: attempt 0 failures 0
> debug1: PAM: initializing for "root"
> debug1: PAM: setting PAM_RHOST to "mainhost"
> debug1: PAM: setting PAM_TTY to "ssh"
> debug1: temporarily_use_uid: 0/0 (e=0/0)
> debug1: trying public key file /root/.ssh/authorized_keys
> debug1: restore_uid: 0/0
> debug1: temporarily_use_uid: 0/0 (e=0/0)
> debug1: trying public key file /root/.ssh/authorized_keys2
> debug1: restore_uid: 0/0
> Failed publickey for root from 172.x.x.x port 54630 ssh2
>
>
> -----Original Message-----
> From: address@hidden [mailto:address@hidden On Behalf Of Jeff Forcier
> Sent: Wednesday, June 27, 2012 2:12 PM
> To: Ashby, Jason (IMS)
> Cc: address@hidden
> Subject: Re: [Fab-user] Loading system known_hosts file
>
> Hi Jason,
>
> Fabric should be doing this correctly, and if you check your debug
> output, you'll notice that it appears to be using the right key:
>
>> DEBUG:ssh.transport:Trying key 2d84d6f8af827bd2008aa7e8009fb3765 from
>> /etc/ssh/ssh_host_rsa_key
>>
>> DEBUG:ssh.transport:userauth is OK
>>
>> INFO:ssh.transport:Authentication (publickey) failed.
>
> What this means is the server rejected that key for some reason.
> There's no way to tell without enabling debug output on the server
> sshd, restarting it, trying again & then checking the server's sshd or
> auth logs.
>
> Have you tried using this key with regular 'ssh' before? E.g.:
>
>     ssh -t -i /etc/ssh/ssh_host_rsa_key myhost uname -s
>
> Which is roughly equivalent to what Fabric is doing here.
>
> Good luck,
> Jeff
>
>
> On Wed, Jun 27, 2012 at 8:39 AM, Ashby, Jason (IMS) <address@hidden> wrote:
>> Hi,
>>
>> Is it possible for Fabric to use the "system" known hosts and key file found
>> in /etc/ssh/ssh_known_hosts?  We keep all of our host keys in
>> /etc/ssh/ssh_known_hosts and not in individual user's home dirs. (~/.ssh).
>>
>>
>>
>> I've tried the following env settings:
>>
>>
>>
>> env.use_ssh_config = True
>>
>> env.ssh_config_path = '/etc/ssh/ssh_config'
>>
>> env.key_filename = '/etc/ssh/ssh_host_rsa_key'
>>
>>
>>
>> However, I'm still prompted for a password.  I can hostbased SSH from
>> mainhost to foohost without a password as root when testing from the Linux
>> command line.  Here is some debug output:
>>
>>
>>
>> address@hidden:~ > fab test
>>
>> [foohost] Executing task 'test'
>>
>> [foohost] run: uname -s
>>
>> DEBUG:ssh.transport:starting thread (client mode): 0x26f2890L
>>
>> INFO:ssh.transport:Connected (version 1.99, client OpenSSH_5.1)
>>
>> DEBUG:ssh.transport:kex algos:['diffie-hellman-group-exchange-sha256',
>> 'diffie-hellman-group-exchange-sha1', 'diffie
>> -hellman-group14-sha1', 'diffie-hellman-group1-sha1'] server key:['ssh-rsa',
>> 'ssh-dss'] client encrypt:['aes128-cbc'                   , '3des-cbc',
>> 'blowfish-cbc', 'cast128-cbc', 'arcfour128', 'arcfour256', 'arcfour',
>> 'aes192-cbc', 'aes256-cbc', 'rij
>> address@hidden', 'aes128-ctr', 'aes192-ctr', 'aes256-ctr'] server
>> encrypt:['aes128-cbc', '3des-cbc', 'blow                   fish-cbc',
>> 'cast128-cbc', 'arcfour128', 'arcfour256', 'arcfour', 'aes192-cbc',
>> 'aes256-cbc', 'address@hidden                   iu.se',
>> 'aes128-ctr', 'aes192-ctr', 'aes256-ctr'] client mac:['hmac-md5',
>> 'hmac-sha1', 'address@hidden', 'hmac-                   ripemd160',
>> 'address@hidden', 'hmac-sha1-96', 'hmac-md5-96'] server
>> mac:['hmac-md5', 'hmac-sha1', 'umac-                   address@hidden',
>> 'hmac-ripemd160', 'address@hidden', 'hmac-sha1-96',
>> 'hmac-md5-96'] client compress:['no                   ne',
>> 'address@hidden', 'zlib'] server compress:['none', 'address@hidden',
>> 'zlib'] client lang:[''] server lang:[                   ''] kex
>> follows?False
>>
>> DEBUG:ssh.transport:Ciphers agreed: local=aes128-ctr, remote=aes128-ctr
>>
>> DEBUG:ssh.transport:using kex diffie-hellman-group1-sha1; server key type
>> ssh-rsa; cipher: local aes128-ctr, remote                    aes128-ctr;
>> mac: local hmac-sha1, remote hmac-sha1; compression: local none, remote none
>>
>> DEBUG:ssh.transport:Switch to new keys ...
>>
>> DEBUG:ssh.transport:Trying key 2d84d6f8af827bd2008aa7e8009fb3765 from
>> /etc/ssh/ssh_host_rsa_key
>>
>> DEBUG:ssh.transport:userauth is OK
>>
>> INFO:ssh.transport:Authentication (publickey) failed.
>>
>> [foohost] Login password for 'root':
>>
>>
>>
>>
>>
>> FYI, the test function is just:
>>
>>
>>
>> def test():
>>
>>                   run('uname -s')
>>
>>
>>
>>
>>
>> VERSION INFO:
>>
>> root@ mainhost:~> fab --version
>>
>> Fabric 1.4.2
>>
>> ssh (library) 1.7.14
>>
>>
>>
>> Thanks for your help!
>>
>>
>> ________________________________
>>
>> Information in this e-mail may be confidential. It is intended only for the
>> addressee(s) identified above. If you are not the addressee(s), or an
>> employee or agent of the addressee(s), please note that any dissemination,
>> distribution, or copying of this communication is strictly prohibited. If
>> you have received this e-mail in error, please notify the sender of the
>> error.
>>
>> _______________________________________________
>> Fab-user mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/fab-user
>>
>
>
>
> --
> Jeff Forcier
> Unix sysadmin; Python/Ruby engineer
> http://bitprophet.org
>
> ________________________________
>
> Information in this e-mail may be confidential. It is intended only for the 
> addressee(s) identified above. If you are not the addressee(s), or an 
> employee or agent of the addressee(s), please note that any dissemination, 
> distribution, or copying of this communication is strictly prohibited. If you 
> have received this e-mail in error, please notify the sender of the error.



--
Jeff Forcier
Unix sysadmin; Python/Ruby engineer
http://bitprophet.org

________________________________

Information in this e-mail may be confidential. It is intended only for the 
addressee(s) identified above. If you are not the addressee(s), or an employee 
or agent of the addressee(s), please note that any dissemination, distribution, 
or copying of this communication is strictly prohibited. If you have received 
this e-mail in error, please notify the sender of the error.