Support Questions

Find answers, ask questions, and share your expertise

HDP 2.4.0 Sandbox: documentation typo regarding SSH access

avatar
Contributor

The HDP 2.4.0 Sandbox has instructions regarding SSH access on the welcome page:

localhost:8888 -> get started -> advanced options

The SSH port is documented to be 22. But at least in the VirtualBox version of sandbox, SSH is actually forwarded to port 2222.

Can the welcome page be fixed?

1 ACCEPTED SOLUTION

avatar
Expert Contributor

Hello,

@Michael Häusler the splash page has been changed to identify localhost as 127.0.0.1 now as well, on new boot all machines will fetch the new splash page and port 2222 proper will be displayed in both cases ( provided they have access to github.com.

@Lester Martin the way port forwarding works is that it exposes port 22 of the sandbox machine to the outside network of your PC via port 2222.

From your command history I see that you seem to already be inside the sandbox virtual machine ([root@sandbox ~]) and therefore it's working as designed allowing you to ssh to itself from inside at port 22, but not allowing you to ssh to itself at port 2222 since that functionality is offered via Virtualbox NAT.

Sorry for the confusion caused by the web script, it should be cleared now.

View solution in original post

11 REPLIES 11

avatar
Master Mentor

I will tag the documentation team. Thanks for the catch! @Michael Häusler

avatar

Based on my findings, I'm not sure we have anything to change on the documentation front. We could probably build something in the webapp itself that creates that splash screen to provide some more details (or an error?) if you come in as http://localhost:8888.

avatar
Master Mentor

avatar

Interesting, my copy (I'm also using VirtualBox) shows 2222 as I'm pasting below from the 8888 splash page. It doesn't make it painfully obvious you should type "ssh root@127.0.0.1 -p 2222", but it does look correct. Can you paste a screenshot @Michael Häusler as well as the exact URL you used to pull down the Sandbox VM?

Secure Shell (SSH) Client

With an SSH client of your choice use the following credentials: IP: 127.0.0.1 port: 2222 username: root password: hadoop

avatar
Contributor

It seems to depend on whether you enter 127.0.0.1:8888 or localhost:8888 in your browser:

  • 127.0.0.1:8888 shows port 2222
  • localhost:8888 shows port 22

Screenshot attached.

2540-localhost-vs-127-0-0-1.jpg

avatar
Master Mentor

amazing catch!

avatar

I think I figured it out. I was able to verify the two different ports (2222 and 22) are displayed based on it you hit 127.0.0.1:8888 or localhost:8888 in your browser as @Michael Häusler's side-by-side screenshot shows. I double-checked the port forwarding in VirtualBox as shown below.

2555-portforwarding.jpg

No matter which way you hit it via the browser, we are always going to port 8888 on the Sandbox itself. It seems there is some logic in the webapp that you hit that leverages which address you used to get to it. Thankfully, the on-screen instructions drive you to use http://127.0.0.1:8888/.

If you look close, you'll see that the all the hostnames on that splash screen change between 127.0.0.1 and localhost based on the original URL you use. I believe the reason the webapp is doing this is based on if you were actually running a windowing system on the Sandbox itself. We are basically just SSH'ing in and aren't using a windowing interface.

My hunch then was that depending on where you are accessing this makes a difference and I did validate that by some SSH testing. If you are coming in from your host OS then you can only SSH over port 2222, but it doesn't matter if you say localhost or 127.0.0.1.

HW10653-2:~ lmartin$ ssh root@127.0.0.1 -p 22
ssh: connect to host 127.0.0.1 port 22: Connection refused
HW10653-2:~ lmartin$ ssh root@localhost -p 22
ssh: connect to host localhost port 22: Connection refused
HW10653-2:~ lmartin$ ssh root@localhost -p 2222
root@localhost's password:
Last login: Wed Mar  2 23:18:00 2016 from 10.0.2.2
[root@sandbox ~]# exit
logout
Connection to localhost closed.
HW10653-2:~ lmartin$ ssh root@127.0.0.1 -p 2222
root@127.0.0.1's password:
Last login: Wed Mar  2 23:19:13 2016 from 10.0.2.2
[root@sandbox ~]# 

Conversely, once you "in" the Sandbox (in the following case it doesn't matter if you SSH'd in or if you were logged in via a windowing manager) you can only use port 22; again, it doesn't matter how you refer to the hostname.

[root@sandbox ~]# ssh root@127.0.0.1 -p 22
Last login: Wed Mar  2 23:26:13 2016 from 10.0.2.2
[root@sandbox ~]# ssh root@localhost -p 22
Last login: Wed Mar  2 23:27:10 2016 from 127.0.0.1
[root@sandbox ~]# ssh root@localhost -p 2222
ssh: connect to host localhost port 2222: Connection refused
[root@sandbox ~]# ssh root@127.0.0.1 -p 2222
ssh: connect to host 127.0.0.1 port 2222: Connection refused
[root@sandbox ~]#

I'd have to put my networking cap on tighter than it is right now to fully explain why this is the case, but with these limitations in play of port 22 and 222 depending on if you are currently logged into the Host OS or the Guest OS, we really do need the splash screen to be dynamic like it is now.

That said, it is easy to see why one would get confused if they got creative and just started with http://localhost:8888 instead of http://127.0.0.1:8888 as the instructions said.

avatar
Expert Contributor

Hello,

@Michael Häusler the splash page has been changed to identify localhost as 127.0.0.1 now as well, on new boot all machines will fetch the new splash page and port 2222 proper will be displayed in both cases ( provided they have access to github.com.

@Lester Martin the way port forwarding works is that it exposes port 22 of the sandbox machine to the outside network of your PC via port 2222.

From your command history I see that you seem to already be inside the sandbox virtual machine ([root@sandbox ~]) and therefore it's working as designed allowing you to ssh to itself from inside at port 22, but not allowing you to ssh to itself at port 2222 since that functionality is offered via Virtualbox NAT.

Sorry for the confusion caused by the web script, it should be cleared now.

avatar
Contributor

Thanks for the quick fix @glupu