Member Avatar for Djmann1013

I'm trying to host a Minecraft server on a Openshift DIY gear and my friend wants to join.

I have a SSH key for him, and when I run this in cmd like the documentation says:

"C:\Users\~Jacob\Desktop\putty.exe" -ssh -i "C:\Users\~Jacob\Documents\ssh.ppk" -N -L 127.5.90.1:25565:127.5.90.1:25565 53fd2ff4e0b8cd67260003c5@minecraft-awesomeserver.rhcloud.com

It says in PuTTY that it is authenticating and gets stuck at "authenticating key". I can type and stuff but the commands don't execute. I had to add the extra commands from the original documentation because ssh alone doesn't work and without mentioning the .ppk file it will not attempt to connect, as the server will refuse to connect.

Here is the documentation:

The part where you see "add friends" I followed. I guess since the tutorial is outdated the commands broke or something but I know there is a way without rhc tools and git installed because I can access my server via SSH without those, its just when I try tunneling using the command line is the issue. I just don't want other people having full access to my other projects also on the host, and also for them having to download all that stuff is a pian.

Anyone know what to do in my situation?

  • 3 Contributors
  • 2 Replies
  • 242 Views
  • 13 Hours Discussion Span
  • Latest Post Latest Post by rubberman

Dani AI

Generated

A compact, practical checklist to diagnose the "authenticating key" stall and get a tunneled Minecraft client working. The original command was tunnel-focused (as observed), and ’s mention of known_hosts is unlikely to be the root cause (known_hosts stores host fingerprints, not authorized public keys). Focus on three areas: client debug, server-side key/permissions, and verifying the forwarding itself.

Start with a verbose client test (this shows whether authentication actually succeeds and where it stops):

ssh -vvv -i /path/to/key user@host

# On Windows, use PuTTY's command-line tool for verbose output:
plink -v -i C:\path\to\key.ppk user@host

If the key is passphrase-protected, load it into Pageant or let PuTTY prompt; a hidden passphrase prompt can look like a hang.

Server-side checks (these commonly fix mysterious auth failures):

  • Confirm the collaborator's public key is present in the target account's ~/.ssh/authorized_keys as a single line (no extra CR/LF or wrapping).
  • Fix permissions: chmod 700 ~/.ssh and chmod 600 ~/.ssh/authorized_keys.
  • Compare fingerprints (e.g., ssh-keygen -lf /path/to/friend.pub) against what the server has.
  • Watch auth logs while attempting a connection: sudo tail -f /var/log/auth.log (or /var/log/secure).

Verify the tunnel and limit exposure:

  • After authentication, confirm the local forward is listening (netstat -an | grep 25565 on Linux or netstat -an | findstr 25565 on Windows) and test with telnet 127.0.0.1 25565.
  • To avoid giving full shell access, place restrictions in authorized_keys for that key. Example prefix to allow only a single forward and no shell/agents:
no-pty,no-agent-forwarding,no-X11-forwarding,permitopen="127.0.0.1:25565" ssh-rsa AAAAB3... comment

If the instance runs on a PaaS, confirm whether the platform manages SSH keys centrally (some providers require using their tooling to add collaborators). Collecting the client's verbose output and the server's last auth log lines is the fastest way to see whether the problem is a key mismatch, a permissions issue, a passphrase prompt, or a provider-side restriction.

Recommended Answers

All 2 Replies

Member Avatar for been.coerced

The settings as you've given there, does just what it's suppose to do, it didn't start a commandline shell given the -N option ;)

But it did authenticate, and the port forwarding is suppose to have been setup (those -L lines), else it should've given a authentication error.
So now you should follow the rest of the instructions to have the minecraft client connect to the server using your locally forwarded ports.

See here for the explanation:

3.7.3.12 `-N': suppress starting a shell or command

   The `-N' option prevents PuTTY from attempting to start a shell or
   command on the remote server. You might want to use this option if
   you are only using the SSH connection for port forwarding, and your
   user account on the server does not have the ability to run a shell.

   This feature is only available in SSH protocol version 2 (since the
   version 1 protocol assumes you will always want to run a shell).

   This option is equivalent to the `Don't start a shell or command at
   all' checkbox in the SSH panel of the PuTTY configuration box (see
   section 4.18.3).
Member Avatar for rubberman

The remote user's ip address has to be registered in the ~/.ssh/known_hosts database. You might want to review the ssh man pages for better understanding of what is needed for remote connection with ssh keys.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.