Configuring OpenSSH 3.5p1

John Harrop johnh at sjgeophysics.com
Sat Jun 14 04:18:25 EDT 2003


Thanks for the suggestions and comments.  You got me thinking on some
new lines that solved the problem.  Actually there were two problems:

One of my keys had been damaged or changed so that caused some problems.

I also found out that the $HOME/.ssh directory must have no greater than
744 permissions (and I think it installs as 766).  I recall being warned
about this before - but its not as obvious in the docs as permission
requirements of some files.

The new system I'm working on is also running on RedHat 9.  I'm glad to
hear I'm not the only one using it.

Cheers,

John Harrop
Geologist
GIS and Software Development Manager
SJ Geophysics Ltd

On Thu, 2003-06-12 at 23:31, Santiago Muelas wrote:
> I'm running RedHat-9. Everything works perfectly with the simple generation of the key (Using ssh-keygen and putting the result on directory .ssh). Very clear explained on "man ssh". Nothing more to be done.
> 
> 
> 
> 
> On Thu, 12 Jun 2003 14:11:41 -0400 (EDT)
> "Robert G. Brown" <rgb at phy.duke.edu> wrote:
> 
> > On 12 Jun 2003, John Harrop wrote:
> > 
> > > I'm currently building a new cluster which unlike the older, more
> > > isolated one will be using OpenSSH.  How are others configuring their
> > > ssh?  
> > > 
> > > I've been trying to keep the system in the 'recommended' settings of the
> > > O'Reilly SSH book but I'm having trouble getting automatic password
> > > authentication.  (The passphrase authentication is fine.)  For example,
> > > ssh-agent handles the passphrase fine, but I can't seem to get
> > > /etc/shosts.equiv or .shosts to work with the password.
> > > 
> > > Has the security tightened up on OpenSSH since the book?  Assistance
> > > would be appreciated - I have a feeling I'm missing something simple in
> > > all the ssh options, files and permissions!
> > 
> > Unfortunately there are several places where authentication can occur
> > (or not) in an ssh connection.  Running ssh -v when trying can often
> > help figure out what fails.
> > 
> > I'm not quite clear on what you mean by "getting automatic password
> > authentication".  Ssh/sshd usually come preconfigured in a mode that
> > requires that you enter your password when ssh-connecting to any host
> > running the sshd.  To configure it so that you DON'T need a password to
> > run a remote shell command (for example so you can do things like):
> > 
> > rgb at lilith|T:104>ssh ganesh ls -ald .ssh
> > drwxr-xr-x    3 rgb      prof         4096 Nov  7  2002 .ssh
> > 
> > you need to generate a key pair.  The tool for this is ssh-keygen, and
> > you can create either RSA (ssh 1) or DSA (ssh 2) keys.  One place you
> > COULD be failing is that sshd can be configured to permit logins using
> > keypairs or not.  Read man sshd_config.
> > 
> > In most versions of ssh these days, I'm pretty sure .shosts and
> > /etc/shosts.equiv is pretty much ignored in favor of the much stronger
> > rsa/dsa host identification.
> > 
> > I enclose below a trace of ssh -v in a successful remote login with no
> > password.  Note that it gets down to where it needs to authenticate,
> > announces that it can do so via either publickey (a keypair) or a
> > password (where it has already validated the host identity) and then
> > uses the publickey successfully.
> > 
> > HTH,
> > 
> >    rgb
> > 
> > -- 
> > Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
> > Duke University Dept. of Physics, Box 90305
> > Durham, N.C. 27708-0305
> > Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb at phy.duke.edu
> > 
> > 
> > rgb at lilith|T:109>ssh -v ganesh
> > OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090701f
> > debug1: Reading configuration data /etc/ssh/ssh_config
> > debug1: Applying options for *
> > debug1: Rhosts Authentication disabled, originating port will not be
> > trusted.
> > debug1: ssh_connect: needpriv 0
> > debug1: Connecting to ganesh [152.3.182.51] port 22.
> > debug1: Connection established.
> > debug1: identity file /home/rgb/.ssh/identity type 0
> > debug1: identity file /home/rgb/.ssh/id_rsa type -1
> > debug1: identity file /home/rgb/.ssh/id_dsa type 2
> > debug1: Remote protocol version 1.99, remote software version
> > OpenSSH_3.1p1
> > debug1: match: OpenSSH_3.1p1 pat OpenSSH_2.*,OpenSSH_3.0*,OpenSSH_3.1*
> > debug1: Enabling compatibility mode for protocol 2.0
> > debug1: Local version string SSH-2.0-OpenSSH_3.5p1
> > debug1: SSH2_MSG_KEXINIT sent
> > debug1: SSH2_MSG_KEXINIT received
> > debug1: kex: server->client aes128-cbc hmac-md5 none
> > debug1: kex: client->server aes128-cbc hmac-md5 none
> > debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
> > debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
> > debug1: dh_gen_key: priv key bits set: 127/256
> > debug1: bits set: 1577/3191
> > debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
> > debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
> > debug1: Host 'ganesh' is known and matches the RSA host key.
> > debug1: Found key in /home/rgb/.ssh/known_hosts2:1
> > debug1: bits set: 1617/3191
> > debug1: ssh_rsa_verify: signature correct
> > debug1: kex_derive_keys
> > debug1: newkeys: mode 1
> > debug1: SSH2_MSG_NEWKEYS sent
> > debug1: waiting for SSH2_MSG_NEWKEYS
> > debug1: newkeys: mode 0
> > debug1: SSH2_MSG_NEWKEYS received
> > debug1: done: ssh_kex2.
> > debug1: send SSH2_MSG_SERVICE_REQUEST
> > debug1: service_accept: ssh-userauth
> > debug1: got SSH2_MSG_SERVICE_ACCEPT
> > debug1: authentications that can continue: publickey,password
> > debug1: next auth method to try is publickey
> > debug1: try privkey: /home/rgb/.ssh/id_rsa
> > debug1: try pubkey: /home/rgb/.ssh/id_dsa
> > debug1: input_userauth_pk_ok: pkalg ssh-dss blen 435 lastkey 0x808bb10
> > hint 2
> > debug1: read PEM private key done: type DSA
> > debug1: ssh-userauth2 successful: method publickey
> > debug1: channel 0: new [client-session]
> > debug1: send channel open 0
> > debug1: Entering interactive session.
> > debug1: ssh_session2_setup: id 0
> > debug1: channel request 0: pty-req
> > debug1: Requesting X11 forwarding with authentication spoofing.
> > debug1: channel request 0: x11-req
> > debug1: channel request 0: shell
> > debug1: fd 3 setting TCP_NODELAY
> > debug1: channel 0: open confirm rwindow 0 rmax 32768
> > Last login: Thu Jun 12 13:56:58 2003 from rgb.adsl.duke.edu
> > rgb at ganesh|T:101>
> > 
> > _______________________________________________
> > Beowulf mailing list, Beowulf at beowulf.org
> > To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
> 
> 
> -- 
> Santiago Muelas
> Profesor de Resistencia de Materiales y Cálculo de Estructuras
> ETSI de Caminos, Canales y Puertos (U.P.M)
> smuelas at mecanica.upm.es		http://w3.mecanica.upm.es/~smuelas
> _______________________________________________
> Beowulf mailing list, Beowulf at beowulf.org
> To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf


_______________________________________________
Beowulf mailing list, Beowulf at beowulf.org
To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf



More information about the Beowulf mailing list