Configuring OpenSSH 3.5p1
smuelas at mecanica.upm.es
Fri Jun 13 02:31:11 EDT 2003
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.
> 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
> debug1: ssh_connect: needpriv 0
> debug1: Connecting to ganesh [188.8.131.52] 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
> 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
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
More information about the Beowulf