-1
My company has a server (server A) in a data center belonging to a telecoms company. The server has no access from the internet. I need to access this server because of a server application that I am working on.
We have a second server (server B) in the same data center that I can easily ssh into and my colleagues can both ssh and telnet into (server A) from this second server.
I can also telnet (server A) from (server B), but I cannot ssh into (server A) from (server B).
How do I ssh into a server that I can telnet to?
More information as requested:
ssh -v user@domain -p port gives me:
ssh -v root@ip_addr -p 1723
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to ip_addr [ip_addr] port 1723.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/identity-cert type -1
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '[ip_addr]:1723' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
Cannot determine realm for numeric host address
debug1: Unspecified GSS failure. Minor code may provide more information
Cannot determine realm for numeric host address
debug1: Unspecified GSS failure. Minor code may provide more information
debug1: Unspecified GSS failure. Minor code may provide more information
Cannot determine realm for numeric host address
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Trying private key: /root/.ssh/id_ecdsa
debug1: Next authentication method: password
root@ip_addr's password:
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
Last login: Thu Apr 14 20:03:52 2016 from another_ip
[root@localhost ~]#
This logs me in.
But afterwards the normal ssh user@domain -p still does not work.
gbenroscience
Posted 2016-04-15T01:10:53.773
Reputation: 107
How do you mean? They have looked at the commands I used and everything is in order. What other information do you need please? – gbenroscience – 2016-04-15T01:18:10.627
Its not a pride issue, of not wanting to ask them or something. We have tried to do it together from my system and we all failed...so you see? please I just need to solve this problem. – gbenroscience – 2016-04-15T01:29:49.887
Hmm, I just succeeded in logging in with ssh -v user@domain -p port_no – gbenroscience – 2016-04-15T01:39:44.557
Yes I think its on port 1723, I just posted the output ssh -v user@domain, please – gbenroscience – 2016-04-15T01:46:14.093
Be sure you answer this question, updating the question to include the answer, isn't appropriate. – Ramhound – 2016-04-15T01:48:04.137
Its not yet answered, ssh -v works, but not the normal ssh user@domain -p [port] What do you think, please? – gbenroscience – 2016-04-15T01:49:15.597
I don't understand. You are authenticated with Server A, by using the key, that exists on Server B, you can't authenticate using that command your trying. – Ramhound – 2016-04-15T01:53:08.937
Please can you explain, I am not a guru at this. – gbenroscience – 2016-04-15T01:54:40.347
Your question makes no sense. You have proven exactly what they said was possible. Work on the question, once its something that can be answered, somebody might answer it. I don't understand where your confusion is though so I can't do that. Of course allowing ssh'ing as root is a huge security problem. – Ramhound – 2016-04-15T01:58:12.410
Wow thanks then. I just didn't understand why the conventional ssh user@domain -p [port] wasn't working. – gbenroscience – 2016-04-15T02:00:10.113
If I were to hazard to guess, the server is miss configured, to allow root ssh and nothing else – Ramhound – 2016-04-15T02:05:45.777
Okay then, but I am logging in as root – gbenroscience – 2016-04-15T02:11:55.713
I just found out that putty was generally been wicked by hanging the interface at the point where the password prompt ought to come up. SO sorry to have bothered you, but the issue was recurring. My solution was to keep resizing the page and staying on the terminal. Thanks – gbenroscience – 2016-04-15T02:31:35.153