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

Re: oo-install and ssh



​Ok, that what I suspected, unfortunately, I don't know why is not working as on my node01.contoso.lan host, I've got the following traces on my SSHD Logs:

Sep  4 15:54:46 node01 sshd[1887]: Server listening on 172.21.10.160 port 22.
Sep  4 15:55:05 node01 sshd[1887]: debug1: Forked child 1890.
Sep  4 15:55:05 node01 sshd[1890]: Set /proc/self/oom_score_adj to 0
Sep  4 15:55:05 node01 sshd[1890]: debug1: rexec start in 4 out 4 newsock 4 pipe 6 sock 7
Sep  4 15:55:05 node01 sshd[1890]: debug1: inetd sockets after dupping: 3, 3
Sep  4 15:55:05 node01 sshd[1890]: Connection from 172.21.10.148 port 50050
Sep  4 15:55:05 node01 sshd[1890]: debug1: Client protocol version 2.0; client software version Ruby/Net::SSH_2.7.0 x86_64-linux
Sep  4 15:55:05 node01 sshd[1890]: debug1: no match: Ruby/Net::SSH_2.7.0 x86_64-linux
Sep  4 15:55:05 node01 sshd[1890]: debug1: Enabling compatibility mode for protocol 2.0
Sep  4 15:55:05 node01 sshd[1890]: debug1: Local version string SSH-2.0-OpenSSH_5.3
Sep  4 15:55:05 node01 sshd[1891]: debug1: permanently_set_uid: 74/74
Sep  4 15:55:05 node01 sshd[1891]: debug1: list_hostkey_types: ssh-rsa
Sep  4 15:55:05 node01 sshd[1891]: debug1: SSH2_MSG_KEXINIT sent
Sep  4 15:55:05 node01 sshd[1891]: debug1: SSH2_MSG_KEXINIT received
Sep  4 15:55:05 node01 sshd[1891]: debug1: kex: client->server aes128-cbc hmac-sha1 none
Sep  4 15:55:05 node01 sshd[1891]: debug1: kex: server->client aes128-cbc hmac-sha1 none
Sep  4 15:55:05 node01 sshd[1891]: debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
Sep  4 15:55:05 node01 sshd[1891]: debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
Sep  4 15:55:05 node01 sshd[1891]: debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
Sep  4 15:55:05 node01 sshd[1891]: debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
Sep  4 15:55:05 node01 sshd[1891]: debug1: SSH2_MSG_NEWKEYS sent
Sep  4 15:55:05 node01 sshd[1891]: debug1: expecting SSH2_MSG_NEWKEYS
Sep  4 15:55:05 node01 sshd[1891]: debug1: SSH2_MSG_NEWKEYS received
Sep  4 15:55:05 node01 sshd[1891]: debug1: KEX done
Sep  4 15:55:05 node01 sshd[1891]: Connection closed by 172.21.10.148
Sep  4 15:55:05 node01 sshd[1891]: debug1: do_cleanup
Sep  4 15:55:05 node01 sshd[1890]: debug1: do_cleanup

Which seems to be perfectly OK for me regarding the SSHD_Configuration on my remote host.

​About the ssh-agent, ok thx for the confirmation, that was my primary educated guess but I'd to confirm it to be sure.

I hope someone could lead us on this topic, I feel that the last fence on my way to have a working demo platform :D



2014-09-04 15:46 GMT+02:00 N. Harrison Ripps <hripps redhat com>:

> 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
>
>



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