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.

Everyday I wake up and check the my servers are running smooth, I use my mac to connect to some ubuntu and some freebsd machines.

But today when I tried something strange happened:

$ ssh -v -p 41900 someserver.com
OpenSSH_5.2p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data /etc/ssh_config
debug1: Connecting to someserver.com [95.166.12.75] port 41900.
debug1: Connection established.
debug1: identity file /Users/someuser/.ssh/identity type -1
debug1: identity file /Users/someuser/.ssh/id_rsa type -1
debug1: identity file /Users/someuser/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8p2_hpn13v11 FreeBSD-20110503
debug1: match: OpenSSH_5.8p2_hpn13v11 FreeBSD-20110503 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.2
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 '[someserver.com]:41900' is known and matches the RSA host key.
debug1: Found key in /Users/someuser/.ssh/known_hosts:3
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,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: /Users/someuser/.ssh/id_dsa
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Trying private key: /Users/someuser/.ssh/identity
debug1: Trying private key: /Users/someuser/.ssh/id_rsa
debug1: Next authentication method: keyboard-interactive
Password:
debug1: Authentication succeeded (keyboard-interactive).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.

Now the connection just hangs, nothing happenes -- until it timesout and shuts down after some minutes.

[UPDATE]

After having tried putting my laptop into a bag and going to another network, I have come to beleave that this is a network issue, and my instincts were confirmed when I found out that my ISP had gone bankrupt.

However, this raises a new question, becaurse I tried loggin onto another network using vpn, but the same issue accured, can anyone explain how a routing problem on one network can affect a vpn connection -- that is othervise running fine?

Can anyone tell me what happened to my ssh client? And perhaps even how I fix it?

share|improve this question
    
It's not your ssh client. You're in an interactive session. Try typing 'ls' and see if you get any output. I'm willing to bet that you do. –  Alex Holst May 15 '12 at 16:44
    
Is there anyone who can log into the server and see what's happening on the other side? Since it looks like you're able to get into the box, but your session isn't initializing properly, perhaps because of load, perhaps because of something in your .profile, etc. It's hard to tell without seeing what's going on from the server side. –  cjc May 15 '12 at 16:44
    
@AlexHolst: I'm getting the same error when logging into a ubuntu box at my university, hangs in the same place. and entering commands has no effect –  Martin Kristiansen May 15 '12 at 16:47
    
I would sometimes see the exact same problem when I connected with ssh from my OpenBSD laptop to some Ubuntu machines. I could always type into the session and run commands, though. Dropping the connection and reconnecting would work so I never really looked into it. Does it happen on every connect? Can you do 'ssh example.com echo hello'? –  Alex Holst May 15 '12 at 16:57
    
I'm gonna get in my car and Go check out the server, that way I can atleast ruleout routing problems. –  Martin Kristiansen May 15 '12 at 17:03

2 Answers 2

This is more likely to be a server issue than a client issue. The connection has been made and authenticated and the client is now waiting for the server to start the session (which I think means forking an sshd process for the user and starting the user's shell). This can be caused by the server being under some kind of load (such as memory and disk IO).

Check that the other services the server is providing are operational -- this could confirm problems on the server. Also try connecting from another network location to rule out weird network issues.

Edit: So this is a client networking issue. Most of the problems where I've seen connections work initially but then hang later on have been caused by MTU problems -- the initial packets (the SSH negotiation in this case) are small enough to pass through, but when actual data gets sent (like drawing a terminal window) the packets are too big and get dropped somewhere. Try decreasing the MTU on your client and trying again.

share|improve this answer
    
I've tried to login to several different servers, So I think I can rule out a server Error. –  Martin Kristiansen May 15 '12 at 17:01
    
After getting in my car and driving closer to the server, I can rule out a server issue. The ssh works perfect, using the same client and server, but a different network. I believe my network is in trouble. –  Martin Kristiansen May 15 '12 at 18:03
    
Added a suggestion regarding the networking issue. –  mgorven May 15 '12 at 18:09
    
@mgroven: how would I decrece the MTU on ssh? –  Martin Kristiansen May 21 '12 at 9:54
1  
I don't know how to adjust the MTU on OS X. –  mgorven May 21 '12 at 17:18

Check this http://www.openssh.com/txt/release-5.1

  • Added a no-more-sessions@openssh.com global request extension that is sent from ssh(1) to sshd(8) when the client knows that it will never request another session (i.e. when session multiplexing is disabled). This allows a server to disallow further session requests and terminate the session in cases where the client has been hijacked.
share|improve this answer
1  
I don't think this is relevant... –  mgorven May 15 '12 at 16:41

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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