Loading Profile...
Hanging after short time period, keyboard-interactive's fault?
I'm using Expandrive to an internal server, and after a few minutes the drive stops responding. It still shows as mounted, but I can't read/write any more files, and directories don't show their contents. I have to eject and re-mount to make it work again (and then it breaks again a few minutes later). In my mac's console log, I get this:
Now, on the server I see this:
I can access files, then time passes... A few minutes later when I try to write a file to the drive:
So I'm not sure if it's the fact that this particular sshd requires keyboard-interactive or what, but I could have sworn this used to work great for months at a time before I rebuilt my mac. I do know that this boks_sshd (a corporate standard we're required to use) does require the use of the keyboard-interactive authentication, which obviously works at first.
I've tried the current production release as well as the last 2 beta releases. The above is with 1.3.2b5 It happens with or without using TextMate (although the goal here is really to use TextMate once it works). Regular ssh terminal sessions to this server don't time out after 5 minutes.
Just thought I'd throw my experience out there, hoping for a coming release that will fix the issue. Thanks!
11/21/08 4:54:20 PM fseventsd[48] scan_old: bailing out because device mounted @ /Volumes/icd07 has dls 0x0 and dls->fci 0x0
11/21/08 4:54:30 PM kernel MacFUSE: force ejecting (no response from user space 5)
11/21/08 4:54:30 PM TextMate[1424] saveMetaData:forView: error: setattr() lost POSIX file permissions for /Volumes/icd07/svn/lib-perl/LNSTools/root/content/index (420 -> (null))
11/21/08 4:54:31 PM KernelEventAgent[45] tid 00000000 received VQ_DEAD event (32)
Now, on the server I see this:
Nov 21 16:47:57 icd07 boks_sshd[4997]: Accepted keyboard-interactive/boksauth for XXXXX from X.X.X.X port 49805 ssh2
Nov 21 16:47:57 icd07 boks_sshd[4997]: subsystem request for sftp
I can access files, then time passes... A few minutes later when I try to write a file to the drive:
Nov 21 16:53:52 icd07 boks_sshd[4997]: Disconnecting: No terminal authorization granted
So I'm not sure if it's the fact that this particular sshd requires keyboard-interactive or what, but I could have sworn this used to work great for months at a time before I rebuilt my mac. I do know that this boks_sshd (a corporate standard we're required to use) does require the use of the keyboard-interactive authentication, which obviously works at first.
I've tried the current production release as well as the last 2 beta releases. The above is with 1.3.2b5 It happens with or without using TextMate (although the goal here is really to use TextMate once it works). Regular ssh terminal sessions to this server don't time out after 5 minutes.
Just thought I'd throw my experience out there, hoping for a coming release that will fix the issue. Thanks!
I’m puzzled
1
person has this problem
I have this problem, too!
Tell me when someone solves it.
The more people who report this problem, the more it gets noticed.
The more people who report this problem, the more it gets noticed.
-
Inappropriate?Thanks for the heads up. Would it be possible to get a test login to this particular server?
Thanks!
-Jeff
1 person says
this solves the problem
-
Inappropriate?Sorry, it's on a private network. BUT - It works great w/ the new 1.3.2 final. Thanks... hopefully it was something that was fixed in that release!
I’m glad
-
Inappropriate?The error message in this case did not indicate a problem with the software on your Mac.
"Boks_sshd" is a version of OpenSSH which is included with FoxT's BoKS Access Control software. Using BoKS you can completely close access to your servers so only certain people are allowed very specific access.
The error message "No terminal authorization granted" means that your account was in fact NOT granted access to use SSH on this particular server. It could be that the security guys on the server did in fact allow your account to login, but that you were coming from a different IP address than usual.
The fact that you can now login again means that either 1) your access permissions were expanded 2) your workstation again matches one of the allowed IP addresses.
Cheers,
Thomas Sluyter
the Netherlands
EMPLOYEE
