[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: oo-install and ssh



Hi the dude, first things first, your name rocks!

Yes, I know that I can specify per user configuration on ssh_config instead of the system wide one, but as I said, I'm trying to stay close to our internal guidelines, I agree with you, they should stay as close as possible to the standardized installation and keys storage best practices, but, it's not on my hands, I can pop out Labs VMs but I don't have access to the production process ;-)

Anyway, I finally bypassed the internal recommendation as I'm on a lab for now and that I'm authorize to do so, and yeah... it worked like a charm. So, seems that the problem is related to the key's filename as the ssh client is connecting correctly as shown above on the sshd logs in debug mode.

So, thanks a lot everyone, I'll now have to deal with my management to push those recommendations on our internal guidelines.


2014-09-04 22:26 GMT+02:00 The Dude <michael mcconachie hotmail com>:

BB:

You can specify the keys used by any user by adding entries to the ~/.ssh/config file.  If it doesn't exist, create it and hack away.  That will satisfy ssh, which in turn will satisfy the internals as to how the oo-installer is using ssh bindings to do its lookup and yaml file entries based on the discovery it does during the user input phase.

eg:
Host server1.yourdomain.net
  IdentityFile ~/somedir/sillylocation/.ssh/id_dsa
Host server2.yourdomain.net
  IdentityFile /somedir/blah/home/.ssh/id_rsa
PS: you can also gen keys, and it doesn't matter if you use CentOS or RHEL.  If you all make a habit of storing keys in /etc/ (WHY?) then you'll have the same issue each time. Reach out to your CM and ask them to consider using standardized keyfile storage for both security, and obfuscation reasons.

:wq!

MM


Michael J. McConachie | keys.fedoraproject.org | PubKey: 0xEDE583C4
NOTE: The information included and/or attached in this electronic mail transmission may contain confidential or privileged information and is intended solely for the addressee(s). Any unauthorized disclosure, reproduction, distribution or the taking of action in reliance on the contents of the information are strictly prohibited. If you have received the message in error, please notify the sender by reply transmission and delete the message without copying, disclosing or forwarding.



Date: Thu, 4 Sep 2014 16:04:36 +0200
Subject: Re: oo-install and ssh
From: gael therond gmail com
To: raul laansoo bigbank ee
CC: users lists openshift redhat com


Hi Raul, Yes, usually those IDs are generated by the system on startup but with default config, the server just generate the host_rsa_keys which are as usable as the specific one generated by the root user.

I could try generating id_rsa keys for test purpose on this topic, but it would not be a suitable solution on our next production system based on RHEL instead of CentOS because of some internal nuts process and requirements.


2014-09-04 15:59 GMT+02:00 Raul Laansoo <raul laansoo bigbank ee>:
Hello

> IdentityFile /etc/ssh/ssh_host_rsa_key

Shouldn't this be users (root) identity usually in (~/.ssh), not local server's?

----- Original Message -----
> From: "N. Harrison Ripps" <hripps redhat com>
> To: "Billy Bones" <gael therond gmail com>
> Cc: users lists openshift redhat com
> Sent: Thursday, 4 September, 2014 4:46:23 PM
> Subject: Re: oo-install and ssh
>
>
> > On Sep 4, 2014, at 09:38, Billy Bones <gael therond gmail com> wrote:
> >
> > Hi Harrison,
> >
> > thanks for the quick answer, yes of course my ssh_config file is already
> > set with the correct args as you mentioned it.
> >
> > The thing is, when I'm using ssh client commands, I'm correctly connecting
> > to my remote host, without further arguments that ssh
> > root node01 contoso lan
> > The explicits one upper were there for debug purpose regarding the path
> > where my ids are stored and the current error message ;-)
> >
> > I forgot to post you the whole ssh_config configuration file, I'm sorry for
> > that lack of informations.
> >
> > Here is an extended DEBUG output of my oo-install setup, I'm confuse by the
> > ssh-agent message and I don't know if it is really looking for it, or if
> > it's just a fallback method due to the fact that the previous public key
> > attempt didn't worked.
> >
> >
> > Preflight check: verifying system and resource availability.
> >
> > Checking broker.contoso.lan:
> > * Target host is running CentOS
> > * Located getenforce
> > * SELinux is running in enforcing mode
> > * Located yum
> > * puppet RPM is installed.
> > * openssh-clients RPM is installed.
> > Error: No matching Packages to list
> >
> > Checking node01.contoso.lan:
> > D, [2014-09-04T15:25:04.153886 #1989] DEBUG --
> > net.ssh.transport.session[3f8ea5b84854]: establishing connection to
> > 172.21.10.160:22
> > D, [2014-09-04T15:25:04.156180 #1989] DEBUG --
> > net.ssh.transport.session[3f8ea5b84854]: connection established
> > I, [2014-09-04T15:25:04.156646 #1989]  INFO --
> > net.ssh.transport.server_version[3f8ea5b82c70]: negotiating protocol
> > version
> > D, [2014-09-04T15:25:04.170849 #1989] DEBUG --
> > net.ssh.transport.server_version[3f8ea5b82c70]: remote is
> > `SSH-2.0-OpenSSH_5.3'
> > D, [2014-09-04T15:25:04.171044 #1989] DEBUG --
> > net.ssh.transport.server_version[3f8ea5b82c70]: local is
> > `SSH-2.0-Ruby/Net::SSH_2.7.0 x86_64-linux'
> > D, [2014-09-04T15:25:04.175493 #1989] DEBUG -- tcpsocket[3f8ea5b83170]:
> > read 832 bytes
> > D, [2014-09-04T15:25:04.175870 #1989] DEBUG -- tcpsocket[3f8ea5b83170]:
> > received packet nr 0 type 20 len 828
> > I, [2014-09-04T15:25:04.176087 #1989]  INFO --
> > net.ssh.transport.algorithms[3f8ea5b82c98]: got KEXINIT from server
> > I, [2014-09-04T15:25:04.176483 #1989]  INFO --
> > net.ssh.transport.algorithms[3f8ea5b82c98]: sending KEXINIT
> > D, [2014-09-04T15:25:04.176991 #1989] DEBUG -- tcpsocket[3f8ea5b83170]:
> > queueing packet nr 0 type 20 len 1508
> > D, [2014-09-04T15:25:04.177159 #1989] DEBUG -- tcpsocket[3f8ea5b83170]:
> > sent 1512 bytes
> > I, [2014-09-04T15:25:04.177258 #1989]  INFO --
> > net.ssh.transport.algorithms[3f8ea5b82c98]: negotiating algorithms
> > D, [2014-09-04T15:25:04.177585 #1989] DEBUG --
> > net.ssh.transport.algorithms[3f8ea5b82c98]: negotiated:
> > * kex: diffie-hellman-group-exchange-sha1
> > * host_key: ssh-rsa
> > * encryption_server: aes128-cbc
> > * encryption_client: aes128-cbc
> > * hmac_client: hmac-sha1
> > * hmac_server: hmac-sha1
> > * compression_client: none
> > * compression_server: none
> > * language_client:
> > * language_server:
> > D, [2014-09-04T15:25:04.177722 #1989] DEBUG --
> > net.ssh.transport.algorithms[3f8ea5b82c98]: exchanging keys
> > D, [2014-09-04T15:25:04.178153 #1989] DEBUG -- tcpsocket[3f8ea5b83170]:
> > queueing packet nr 1 type 34 len 20
> > D, [2014-09-04T15:25:04.178310 #1989] DEBUG -- tcpsocket[3f8ea5b83170]:
> > sent 24 bytes
> > D, [2014-09-04T15:25:04.180744 #1989] DEBUG -- tcpsocket[3f8ea5b83170]:
> > read 152 bytes
> > D, [2014-09-04T15:25:04.180993 #1989] DEBUG -- tcpsocket[3f8ea5b83170]:
> > received packet nr 1 type 31 len 148
> > D, [2014-09-04T15:25:04.185064 #1989] DEBUG -- tcpsocket[3f8ea5b83170]:
> > queueing packet nr 2 type 32 len 140
> > D, [2014-09-04T15:25:04.185211 #1989] DEBUG -- tcpsocket[3f8ea5b83170]:
> > sent 144 bytes
> > D, [2014-09-04T15:25:04.190303 #1989] DEBUG -- tcpsocket[3f8ea5b83170]:
> > read 720 bytes
> > D, [2014-09-04T15:25:04.190515 #1989] DEBUG -- tcpsocket[3f8ea5b83170]:
> > received packet nr 2 type 33 len 700
> > D, [2014-09-04T15:25:04.193727 #1989] DEBUG -- tcpsocket[3f8ea5b83170]:
> > queueing packet nr 3 type 21 len 20
> > D, [2014-09-04T15:25:04.193890 #1989] DEBUG -- tcpsocket[3f8ea5b83170]:
> > sent 24 bytes
> > D, [2014-09-04T15:25:04.194123 #1989] DEBUG -- tcpsocket[3f8ea5b83170]:
> > received packet nr 3 type 21 len 12
> > D, [2014-09-04T15:25:04.194821 #1989] DEBUG --
> > net.ssh.authentication.session[3f8ea5b742c4]: beginning authentication of
> > `root'
> > D, [2014-09-04T15:25:04.195098 #1989] DEBUG -- tcpsocket[3f8ea5b83170]:
> > queueing packet nr 4 type 5 len 28
> > D, [2014-09-04T15:25:04.195205 #1989] DEBUG -- tcpsocket[3f8ea5b83170]:
> > sent 52 bytes
> > D, [2014-09-04T15:25:04.234336 #1989] DEBUG -- tcpsocket[3f8ea5b83170]:
> > read 52 bytes
> > D, [2014-09-04T15:25:04.234598 #1989] DEBUG -- tcpsocket[3f8ea5b83170]:
> > received packet nr 4 type 6 len 28
> > D, [2014-09-04T15:25:04.234963 #1989] DEBUG --
> > net.ssh.authentication.session[3f8ea5b742c4]: trying publickey
> > D, [2014-09-04T15:25:04.235231 #1989] DEBUG --
> > net.ssh.authentication.agent[3f8ea5b72c30]: connecting to ssh-agent
> > E, [2014-09-04T15:25:04.235387 #1989] ERROR --
> > net.ssh.authentication.agent[3f8ea5b72c30]: could not connect to ssh-agent
> > E, [2014-09-04T15:25:04.235516 #1989] ERROR --
> > net.ssh.authentication.session[3f8ea5b742c4]: all authorization methods
> > failed (tried publickey)
>
> Unfortunately, I am not an SSH expert, and it seems like this is an SSH
> configuration issue. The ssh-agent line is moot; the line above it ("trying
> publickey") is the part where your SSH config should be satisfying the auth.
>
> > * SSH connection could not be established:
> >   "root"
>
> This is oo-install output; SSH has fallen through to manual password entry at
> this point.
>
> Does anyone else have any other SSH config ideas for Mr. Bones to try?
>
> >
> > The deployment check was not successful. See above for specific issues.
> > oo-install exited; removing temporary assets.
> >
> > And for the records here is my ssh_config file:
> >
> > Host node01.contoso.lan
> >         User root
> >         IdentityFile /etc/ssh/ssh_host_rsa_key
> >         RSAAuthentication yes
> >         ForwardX11Trusted yes
> > # Send locale-related environment variables
> >         SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY
> >         LC_MESSAGES
> >         SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
> >         SendEnv LC_IDENTIFICATION LC_ALL LANGUAGE
> >         SendEnv XMODIFIERS
> >
> > If you need any other informations, let me know it.
> >
> >
> > 2014-09-04 15:00 GMT+02:00 N. Harrison Ripps <hripps redhat com>:
> > Hey there--
> >
> > > On Sep 4, 2014, at 07:44, Billy Bones <gael therond gmail com> wrote:
> > >
> > > Hi everyone,
> > >
> > > I'm facing a strange behavior during my oo-install on a centos 6.5 VM.
> > >
> > > I've got two centos, one which is for the broker role (include DBServer
> > > and MSGServer) and the other one which is a gear node.
> > >
> > > During the installation, everything is fine if I'm installing all roles
> > > on only one node, but as soon as I try to separate the roles, the
> > > oo-install doesn't work and stop before the end of the process.
> > >
> > > The oo-install is complaining about the SSH public key access.
> > >
> > > My two nodes are set to only allow SSH access through public keys.
> > > I'm currently on my lab setup so I'm executing everything with the root
> > > user.
> > >
> > > ssh is set to allow root access only using public keys.
> > >
> > > During the oo-install setup, everything is OK and the wizard process
> > > everything until the SSH connection to the node target where is saying:
> > >
> > > D, [2014-09-04T13:28:04.308146 #1823] DEBUG --
> > > net.ssh.authentication.session[3fdd64f3b5ac]: trying publickey
> > > D, [2014-09-04T13:28:04.308381 #1823] DEBUG --
> > > net.ssh.authentication.agent[3fdd64f39f18]: connecting to ssh-agent
> > > E, [2014-09-04T13:28:04.308540 #1823] ERROR --
> > > net.ssh.authentication.agent[3fdd64f39f18]: could not connect to
> > > ssh-agent
> > > E, [2014-09-04T13:28:04.308727 #1823] ERROR --
> > > net.ssh.authentication.session[3fdd64f3b5ac]: all authorization methods
> > > failed (tried publickey)
> > > * SSH connection could not be established:
> > >   "root"
> > >
> > > If I do a:
> > >
> > > ssh -i /etc/ssh/ssh_host_rsa_key root node01 contoso lan everything is
> > > ok, I'm connecting to the remote host as root without any warning
> > > messages.
> >
> > In this example above, you are specifically telling SSH which key to use.
> > In order for oo-install to do the same, you should define this in the SSH
> > configuration on the system where you are running oo-install.
> >
> > To do this, create or open the ~/.ssh/config file and put in an entry like:
> >
> > Host node01.contoso.lan
> >   User         root
> >   HostName     node01.contoso.lan
> >   IdentityFile /etc/ssh/ssh_host_rsa_key
> >
> > And test it by running:
> >
> >     ssh node-1.contoso.lan
> >
> > If you are able to connect with this command, then the configuration is
> > correct.
> >
> > Now when oo-install attempts to connect to the node host, it will
> > implicitly pick up the right key because the ssh configuration file tells
> > it what to use.
> >
> > --Harrison
> >
> > p.s. Advice from another _Treasure Island_ fan: Heed Doctor Livesey's
> > diagnosis, and if I were you I'd leave the Benbow for an inn further
> > inland.
> >
> > >
> > > I'm using the following instruction part to try my Openshift Origin
> > > install:
> > >
> > > Openshift Origin User's Guide
> > >
> > > And I noticed that the installer (as mentioned on the documentation) is
> > > trying a public key unsuccessfully before trying to use ssh-agent, the
> > > problem is that even on debug mode, I can figuring out what is the
> > > public key file that the installer is trying to use.
> > >
> > > I suspect the installer to look for ~.ssh/id_rsa key instead of the
> > > auto-generated on /etc/ssh/ssh_host_rsa_key.
> > >
> > > Is anyone able to help me or at least lead me on this assumption?
> > >
> > > Thanks and regards!
> > > _______________________________________________
> > > users mailing list
> > > users lists openshift redhat com
> > > http://lists.openshift.redhat.com/openshiftmm/listinfo/users
> >
> >
>
>
> _______________________________________________
> users mailing list
> users lists openshift redhat com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>


_______________________________________________ users mailing list users lists openshift redhat com http://lists.openshift.redhat.com/openshiftmm/listinfo/users


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]