Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I can connect to the remote server using following command...

sftp abc@255.136.181.123

But this works from server A and if I use the same command on Server B it does not work.

1) What changes needs to be done by the remote server host to enable server B to be able to connect as well?

2) How do I check the difference from Server A and server B if the service is enabled on server B?

The ping to remote server IP does not work from both the servers and that is not required as well.

share|improve this question

closed as off-topic by HopelessN00b, MichelZ, kasperd, dawud, Wesley Oct 13 at 15:06

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions must demonstrate a minimal understanding of the problem being solved. Try including attempted solutions, why they didn't work, and the expected results. See How can I ask better questions on Server Fault? for further guidance." – HopelessN00b, MichelZ, kasperd, dawud, Wesley
If this question can be reworded to fit the rules in the help center, please edit the question.

1  
Define "doesn't work" first. –  quanta Oct 5 '11 at 6:19
    
What OS are the servers running ? –  Iain Oct 5 '11 at 6:38
    
I am asked for the password after the line # Connecting to 255.136.181.123... # but on second server I am not asked for the password, I have to kill the command using Ctrl + C # using centOS –  shantanuo Oct 5 '11 at 6:47

4 Answers 4

up vote 1 down vote accepted

Practical Solution

Verify that the SSH service is offered on that IP by performing a port scan. If you're not knowledgeable with port scanners, just download the Nmap pack with frontend from http://nmap.org/download.html and perform a standard scan.

If the service is not up, you need to talk to the IT staff in charge of managing that server.

Odds are, SSH is running but not on the default port. A Port scan should reveal the current listening port.

Another possibility is that the SSH daemon on Server B restricted login to certificate users. In that case, you need a public/private SSH key pair.

You can create one following this tutorial: http://jaybyjayfresh.com/2009/02/04/logging-in-without-a-password-certificates-ssh/

Once you have your key pair, you can contact IT to tell them to add your public key to Server B authorized certificates.

How to contact IT

If you can't find the SSH listening port like this, you can formulate a request to the IT staff in this manner

"I need to be able to transfer files via SFTP to Server B. Can you please put the SSH service up if it isn't and tell me the listening port? In case there is a Whitelist set up, please add my Server to it

In the event that Server B is using a certificates authentication scheme, please add my public key to your authorized keys list (attached to the email). "

It is possible Server B has a list of allowed ips to connect to the SSH daemon, the "whitelist" part of the request should take care of that.

While you're at it, ask for a user/password if you don't have a centralized authentication backend.

share|improve this answer
    
telnet ip.add.re.ss 22 is just as effective as a port scan and is unlikely to get the remote systems admin irritated with you by scanning their systems. IN this case the OP is not the admin of the remote system so we can't really help. –  Iain Oct 5 '11 at 7:17
    
i'm suggesting that the daemon is not running on port 22. It could be any port really. Also, there are a number of things that can be done before contacting IT. The less work he needs to have the other side perform, the quicker he will solve his problem. –  ItsGC Oct 5 '11 at 7:24
    
Please take a look here and here regarding your regards and tagline/signature - they are discouraged here. –  Iain Oct 5 '11 at 7:27
    
If someone started remote scanning my systems they would have their IP address blocked very quickly. –  Iain Oct 5 '11 at 7:29
    
Fair enough on the tagline policy. Well, your infrastructure is probably structured enough that a problem like the OP's wouldn't happen. He's been tasked with a problem that can't be solved with the amount of information he has and delegating the issue to a third party is not a real solution. He needs first to gather information, and then act. If it's a public machine, it gets port scanned every day of the week. If it's not public and they belong to the same corporate network, he has reasonable cause for performing the scan. –  ItsGC Oct 5 '11 at 7:31

As you are not the admin of the remote server B there is little you can do. Your best course of action at this point is to contact admin of server B and tell them what is happening and work with them to solve your problem.

share|improve this answer

Its not about sftp i think.

Its about network connectivy.

Have you firewall on 255.136.181.123 ?

share|improve this answer
    
I do not control that server. I need to request for a change to remote server admin. I want to know what needs to be requested. –  shantanuo Oct 5 '11 at 6:44

Sounds like a firewall problem. In that case you need to request a firewall change to open from your ip to 255.136.181.123 port 22 protocol TCP.

Try running sftp -v abc@255.136.181.123 to see if you get any more information.

share|improve this answer
    
What would be the exact command to allow port 22 access to my IP? –  shantanuo Oct 5 '11 at 7:52
    
That depends on what firewall or other access control is in use to stop your IP from connecting. The remote server admin is the best person to know or find that out. –  Johan Nilsson Oct 5 '11 at 19:01

Not the answer you're looking for? Browse other questions tagged or ask your own question.