During login, VSM Server will parse the sshd log file to determine the client IP. If the log contains a line such as: Dec 2 08:56:49 scilla sshd[26475]: pam_vas: Authentication <succeeded passwordless> for <Personality> user: <xpeter> account: <xpeter@cendio.se> service: <sshd> reason: <N/A> Access Control Identifier(NT Name):<CENDIO\xpeter> ...the session creation will fail and vsmserver will give this traceback: 2013-12-03 20:27:35 ERROR vsmserver.session: Unhandled exception trying to start new session for astrand on 127.0.0.1:904: <type 'exceptions.ValueError'> invalid \x escape Traceback (most recent call last): File "/opt/thinlinc/modules/thinlinc/vsm/async.py", line 112, in iii11 obj . handle_read_event ( ) File "/usr/lib64/python2.6/asyncore.py", line 428, in handle_read_event self.handle_read() File "/usr/lib64/python2.6/asynchat.py", line 140, in handle_read self.found_terminator() File "/opt/thinlinc/modules/thinlinc/vsm/xmlrpc.py", line 405, in found_terminator self . handle_response ( ) File "/opt/thinlinc/modules/thinlinc/vsm/xmlrpc.py", line 437, in handle_response self . handle_returnvalue ( ) File "/opt/thinlinc/modules/thinlinc/vsm/call_reqsession.py", line 42, in handle_returnvalue self . callback ( self . returnvalue ) File "/opt/thinlinc/modules/thinlinc/vsm/loginhandler_common.py", line 210, in req_session_finished self.handle_successful_sessionstart() File "/opt/thinlinc/modules/thinlinc/vsm/loginhandler_common.py", line 221, in handle_successful_sessionstart self.sessinfo['client_ip'] = self.get_client_ip() File "/opt/thinlinc/modules/thinlinc/vsm/loginhandler_common.py", line 365, in get_client_ip line = line.decode('string_escape') ValueError: invalid \x escape It will not crash, however. As the traceback above shows, we are parsing the line with line.decode('string_escape'). This is to support non-ASCII usernames; see https://www.cendio.com/bugzilla/show_bug.cgi?id=471#c24. sshd will output escaped string messages. Apparently pam_vas does not.
One solution would be bug 2796.
Fixed in 28209; applied patch from comment #1.
Can't seem to provoke vsmserver into a traceback anymore. Tested build 4294 on Solaris (with judicious modifications to syslog.conf and /vsmserver/sshd_log_files).