Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Broken SSH client on Mavericks

I've read countless posts on broken SSH servers since the upgrade to Mavericks, but I'm having an issue with a broken SSH client. Every time I try to SSH to a remote server, after I type in my password, the prompt just hangs and I just see "Write failed: broken pipe".


I've found many alleged solutions that seem to indicate there are workaround involving decrypting and reincrypting keys and such, but these solutions seem to require using an encryption method that does not allow passwordless keys to work. So I've tried them anyway, using passwords for my new keys, and it still doesn't work. These are steps I used to try and fix it:


$ cd ~/.ssh
$ cp id_rsa id_rsa.bck
$ openssl rsa -in id_rsa -out id_rsa
$ openssl rsa -in id_rsa -aes256 -out id_rsa
$ chmod 0600 id_rsa
$ ssh-keygen -y -f id_rsa > id_rsa.pub


I still get "Write failed: broken pipe". I've tried playing with timeout settings and nothing's working.


Before I upgraded, I had zero problems with SSH whatsoever. All of my co-workers are having the same problem, which has gone uncorrected for weeks and it is hampering my work. How could a problem like this go undetected and ignored? We need a fix for this ASAP. This is crazy.

iMac, OS X Mavericks (10.9)

Posted on Nov 26, 2013 8:02 AM

Reply
38 replies

Nov 26, 2013 8:24 AM in response to impossibleplanet

I am unaware of any problem with ssh in Mavericks. If all of your co-workers are having the same problem, I suspect you are all doing the same thing wrong.


Create a new user accunt on your machine. Take whatever procedures you used to setup your current account, and don't do them. Create an ssh key using default options. Try again. Copy the working settings and permissions from this account to your other accounts.

Nov 26, 2013 10:45 AM in response to etresoft

If by "doing the same thing wrong" you mean updating to Mavericks, then yes, we all did the same thing wrong. Our workflows are different and we don't all use the same settings or keys. Some of us never even set up keys at all and the same problem still arose. We did nothing but upgrade the OS. I've tried creating brand new accounts and even reinstalling the 10.9 update, but the problem persists. This isn't user error and we've been able to reproduce the problem three times. Again, this problem did not exist on 10.8.


I'm not sure that saying you are unaware of any problem with SSH (and telling people they must not know how to do something as basic as set up a user account) is very productive. If you search through these very forums, you'll easily find many people who have had problems with SSH in some form or another after upgrading (hence the commands I posted previously. These were from such discussions). The difference is that most of those seem to be problems with the server, whereas this is a client issue. In the biggest thread about the server issue so far, the agreed upon solution was to completely wipe and reinstall the OS, which is not really an acceptable solution to a problem like this.


I really hope this is fixed in 10.9.1. I've upgraded many Linux systems and had my share of problems, but never has SSH stopped working due to a simple upgrade.

Dec 4, 2013 5:59 AM in response to impossibleplanet

If you are unwilling to do even the most basic troubleshooting like creating a new account or using -v then you are going to have a very difficult time. I don't know what is going on with your system, but installing an update on top of it is the last thing you want to do. This story gets repeated with each and every update. People's systems are misconfigured and they refuse to accep tthat possibility. Then, as each update comes and goes they get ever more angry that their problem isn't fixed.

Dec 4, 2013 6:11 AM in response to etresoft

Are you just trying to be confrontational? Do you get joy out of telling people they are stupid and lazy? Why are you the kind of person that is first to comment on these issues? I'm looking for help, not a scolding. Don't tell me that I'm not making an effort because believe me, I have been.


Clearly you didn't read my update. I did try to create new accounts and it didn't help. The only messages that appear after authenticating are:


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

debug1: Sending env LC_CTYPE = en_US.UTF-8


It doesn't really tell me anything.


There is nothing misconfigured about my system. multiple co-workers have had this same problem and they all have newer systems that have not been modified at all by the IT department. There is no "responsibility" to be "accepted". All I did was update my OS, which apparently makes me an tech-illiterate idiot.


Does anyone have any constructive advice?

Dec 4, 2013 6:24 AM in response to etresoft

Three debug levels yields me this:


debug1: channel 0: new [client-session]

debug3: ssh_session2_open: channel_new: 0

debug2: channel 0: send open

debug1: Requesting no-more-sessions@openssh.com

debug1: Entering interactive session.

debug2: callback start

debug2: fd 3 setting TCP_NODELAY

debug3: packet_set_tos: set IP_TOS 0x10

debug2: client_session2_setup: id 0

debug2: channel 0: request pty-req confirm 1

debug1: Sending environment.

debug3: Ignored env PATH

debug3: Ignored env TMPDIR

debug3: Ignored env SHELL

debug3: Ignored env HOME

debug3: Ignored env USER

debug3: Ignored env LOGNAME

debug3: Ignored env SSH_AUTH_SOCK

debug3: Ignored env Apple_PubSub_Socket_Render

debug3: Ignored env DISPLAY

debug3: Ignored env __CF_USER_TEXT_ENCODING

debug3: Ignored env __CHECKFIX1436934

debug3: Ignored env TERM_PROGRAM

debug3: Ignored env SECURITYSESSIONID

debug3: Ignored env DESTINATION

debug3: Ignored env COMMAND_MODE

debug1: Sending env LANG = en_US.UTF-8

debug2: channel 0: request env confirm 0

debug3: Ignored env PWD

debug3: Ignored env ITERM_PROFILE

debug3: Ignored env TERM

debug3: Ignored env ITERM_SESSION_ID

debug3: Ignored env SHLVL

debug3: Ignored env OLDPWD

debug3: Ignored env GREP_OPTIONS

debug3: Ignored env GREP_COLOR

debug3: Ignored env PAGER

debug3: Ignored env LESS

debug1: Sending env LC_CTYPE = en_US.UTF-8

debug2: channel 0: request env confirm 0

debug3: Ignored env LSCOLORS

debug3: Ignored env _

debug2: channel 0: request shell confirm 1

debug2: callback done

debug2: channel 0: open confirm rwindow 0 rmax 32768

Timeout, server xxx not responding.


I'm not a sysadmin, but I don't see anything that looks like an error, it just dies.


(still hoping for a response sans snark)

Dec 4, 2013 7:51 AM in response to impossibleplanet

impossibleplanet wrote:


(still hoping for a response sans snark)

Now that's going to be difficult, especially when I ask for debug ssh output and you only give me part of it.


Luckily, what you have given me is sufficient. You are authenticating correctly but your server is flaking out just at the last minute. This is a common problem among the many Linux versions out there. It has nothing to do with Mavericks because it existed for many years prior.


I don't know what the actual problem or definitive fix is. If you Google "debug2: channel 0: open confirm rwindow 0 rmax 32768" (with the quotes) you will find any Linux-specific threads on the problem. It could be a reverse DNS problem. It could be a driver problem. It could be a permissions problem. It could be dead sshd processes. It could be that you need to update openssh on the server. The only thing I know for sure is that this is a problem that has existed since 2005 at least. I even found a very similar thread here on ASC where I suggested a very similar Google search 3 years ago. That problem was fixed with a permissions repair and turning off LDAPv3.

Dec 4, 2013 8:18 AM in response to etresoft

The problem may have existed in various places before, but I never ran into it until I upgraded this one machine to Mavericks. Mountain Lion worked just fine, so did Lion, so did Snow Leopard. I can also access these same servers from my home Linux box. So whether or not there is a server-side fix, Mavericks is what introduced the issue, so it seems like a Mavericks problem.


The problem with a server side solution is that it's not just our internal servers that are doing it. I can't interact with external git repositories, either. If this really were a server problem, then not only would everyone else be having the problem, but every SSH server in the world would have to patch their servers, right?


I get what you're saying but literally the only variable for any of us having this problem is Mavericks.


I don't know. I've been looking for solutions for weeks and it probably would have just been easier to downgrade to Mountain Lion and that may be what I have to do but I just can't believe that it's necessary.


Also, I appreciate your help, please don't assume that everyone on the planet knows ssh -v -v -v is the proper debugging method for this particular problem. I bet, by your 22,745 points, that been doing this for a long time, but it's almost never as obvious to everyone as you think it is and most people are unlikely to have same level of google-fu as you or the time to read through 10,000 possible results. (See BobHarris' respectful and level-headed response in the thread you just posted. Compare that to the accusatory tone you took in your very first response to this question). This is the sort of thing that scares off people who are not tech-savvy and I hate it more than anything. I've been in tech support and even if people acted like lazy idiots, I still treated them with respect.

Dec 4, 2013 8:51 AM in response to impossibleplanet

impossibleplanet wrote:


The problem with a server side solution is that it's not just our internal servers that are doing it. I can't interact with external git repositories, either. If this really were a server problem, then not only would everyone else be having the problem, but every SSH server in the world would have to patch their servers, right?


But if it were a Mavericks problem then everyone in the world running Mavericks would have the same issue, right? That is the fundamental difference between OS X and Linux. All Mavericks machines, unless the user messes with them, are identical. Each and every Linux machine is a unique operating system, unlike any other. I don't mean SUSE is different than Ubuntu. I mean two identical-looking Ubutu machines sitting next to each other can, and probably will, be different. Having a LInux server be misconfigured is the rule rather than the exception.


Also, I appreciate your help, please don't assume that everyone on the planet knows ssh -v -v -v is the proper debugging method for this particular problem.


When the topic is using ssh to login into Linux servers, you bet I make that assumption.


I bet, by your 22,745 points, that been doing this for a long time, but it's almost never as obvious to everyone as you think it is and most people are unlikely to have same level of google-fu as you or the time to read through 10,000 possible results. (See BobHarris' respectful and level-headed response in the thread you just posted. Compare that to the accusatory tone you took in your very first response to this question). This is the sort of thing that scares off people who are not tech-savvy and I hate it more than anything. I've been in tech support and even if people acted like lazy idiots, I still treated them with respect.


You have an interested perspective on respect. I am not the one who used the term "idiot" or engaged in any personal attacks. You are welcome to wait for Bob to come along to this thread if you so desire.


I respectually suggest that if you want to get your problem fixed, you should talk to your own IT staff. They have access to the server config files and to the log files. Networking is a complicated endeavour. Just because something works doesn't mean it is configured correctly. One of the telltale indicators that it is improperly configured is a mysterious failure after a client-side update. You will not be able to resolve your issue by looking at only one side of the equation.

Dec 4, 2013 9:50 AM in response to etresoft

I am very concerned at the tone that etresoft is taking on this whole issue. Here is the comment from etresoft;


"If you are unwilling to do even the most basic troubleshooting like creating a new account or using - v gthen you are going to have a very difficult time. I dont know what is going on with your system but installing an update on top of it is the last thing you want to do. This story gets repeated with each and every update. People's systems are misconfigured anbd they refuse to accept that possibility. then, as each update comes and goes they get ever more angry that their problem isn't fixed."


I found this response very alarming. First of all the comment that "installing an update on top of it is the last thing you want to do." Hmmm. Aren't updates supposed to work on top of previous updates from Apple? Since when has it been necessary to completely redo the whole system or, as I have seen in many threads on this problem, simply wipe the hard drive clean and start all over? Apple needs to fix the update entirely, and be willing to pay users for the problems they are encountering, which are many. I have made this recommendation before and will repeat it until Apple is willing to acknowledge their error and back up the Apple name with real service.


I have seen that etresoft has said that users can request an refund if they choose. So this needs to be acknowledged PUBLICLY not just in this forum that Apple needs to be willing to back up their product with refunds for serious errors on Apple's part.


note; I have seen many many comments on these problems when one just googles mavericks. So Apple is already notified of world wide problems on Mavericks. Apple must be willing to acknowledge the error with Mavericks updates and make full refunds without individual requests for refunds.


The tones of the rest of etresoft's responses on this whole issue make me very angry and I am not even affected...yet....since I am very wise and am not going to update to Mavericks. In fact, every time I am notifeid there is an update to my well running Lion system, I refuse the update, lest Apple sneak in a Mavericks "fix" I don't want. I have also recommended to many others who are wishing to buy Apple products that they refuse any products with Mavericks installed.


Last of all is the recommendation later that impossibleplanet contact their IT staff. Did I fail to miss something, but it sounds to me as if impossibleplant is the IT staff..or something very close to an IT staff member. I have read many many many threads on problems IT staffs are encountering with Mavericks, I find it disengenous to ask users with substantial IT knowledge to have to undergo difficult fixes to errors in Apple's programs.


Etresoft and Apple must accept the fact that Mavericks is a flawed update and that the fault does NOT lie with the poor respondents who are being treated as if they are "unwilling to do the most baic troubleshooting" necessary.


So on behalf of the many many respondents to etresoft's comments, I respectfully ask that etresoft acknowledge the update is flawed and use utmost care and COURTESY in helping those with problems.

Dec 4, 2013 11:49 AM in response to First_step


First_step wrote:


I found this response very alarming. First of all the comment that "installing an update on top of it is the last thing you want to do." Hmmm. Aren't updates supposed to work on top of previous updates from Apple?


Alarming? Oh come on! The original poster refered to waiting for 10.9.1 to fix the problem. That is always a bad idea and I said exactly why.


Apple needs to fix the update entirely, and be willing to pay users for the problems they are encountering, which are many.

Pay users because they are trying to ssh into misconfigured Linux servers? Yes! I'm going to be rich!


I have seen that etresoft has said that users can request an refund if they choose.

No, you seem to be following me around in the forums trying to pick a fight. The only reference to a refund request that I have made was in reference to an accidental Mac App Store download.


The tones of the rest of etresoft's responses on this whole issue make me very angry and I am not even affected...

I suggest not getting angry about things that don't affect you. Otherwise, you life will get very unhappy, very quickly.


Last of all is the recommendation later that impossibleplanet contact their IT staff. Did I fail to miss something, but it sounds to me as if impossibleplant is the IT staff..or something very close to an IT staff member. I have read many many many threads on problems IT staffs are encountering with Mavericks, I find it disengenous to ask users with substantial IT knowledge to have to undergo difficult fixes to errors in Apple's programs.

The original poster has made no claim about being part of the IT staff and, in fact, scolded me over my assumption about ssh debugging expertise.


I respectfully ask that etresoft acknowledge the update is flawed

Request denied.


and use utmost care and COURTESY in helping those with problems.

If you, or anyone else, has a problem with the tone of my responses, you are free to use the "report post" button to alert the hosts and ask them to remove or edit myposts. If you do not have the 150 points required to enable that button, you can start a new thread in Using Apple Support Communities and make sure to refer back to this thread so people know what you are referring to. The hosts monitor that forum on a regular basis.


However, I am not an employee of Apple and am I under no obligation to mimic Apple's emotion-free support style. I reserve to the right to act and respond like a normal human being should I feel the need to do so. Bummer.

Broken SSH client on Mavericks

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.