Comment 2 Linn 2022-04-27 11:00:03 CEST

I could reproduce this on RHEL 8 issue with 4.13.0 but not with 4.12.1, so this is a regression from the Python 3 conversion. 

After reproducing the error and then restarting the vsmagent service, also I saw this very similar error in vsmagent.log:
> 2022-04-27 08:51:56 INFO vsmagent: VSM Agent version 4.13.0 build 2253 started
> 2022-04-27 08:51:56 INFO vsmagent: My public hostname is 10.48.2.243
> Traceback (most recent call last):
>   File "/opt/thinlinc/sbin/vsmagent", line 18, in <module>
>     OOoOoo000O00 ( )
>   File "/opt/thinlinc/sbin/vsmagent", line 15, in OOoOoo000O00
>     VSMAgent ( sys . argv )
>   File "/opt/thinlinc/modules/thinlinc/vsm/vsmagent.py", line 149, in __init__
>     self . housekeeping ( )
>   File "/opt/thinlinc/modules/thinlinc/vsm/vsmagent.py", line 181, in housekeeping
>     self . update_sshd_permitopen ( )
>   File "/opt/thinlinc/modules/thinlinc/vsm/vsmagent.py", line 372, in update_sshd_permitopen
>     for ii1 in Oooo0OoOoooo :
>   File "/usr/lib64/python3.6/codecs.py", line 321, in decode
>     (result, consumed) = self._buffer_decode(data, self.errors, final)
> UnicodeDecodeError: 'utf-8' codec can't decode byte 0xd6 in position 4274: invalid continuation byte

If I change the sshd_config file on a fresh RHEL 8 and then install 4.13.0, I don't see this error at the first startup or after restarting vsmagent service.

Comment 3 Linn 2022-05-02 12:19:13 CEST

Note that when adding the ThinLinc specific config to sshd_config, it has to be added at the end of the file. ThinLinc will add a Match block inside the markers, and these Match blocks are recommended to be at the end of the file.

If the ThinLinc specific config is placed elsewhere in the file, users will not be able to log in to the servers and the following errors can be seen:

Error message from native client:
> Server refused the connection. Is this a ThinLinc server?
Error in tlclient.log:
> 2022-05-02T12:18:05: ssh[E]: CONNECT ERROR: 111
Error from sshd:
> sudo journalctl -t sshd
> ...
> May 02 11:25:22 lab-243.lkpg.cendio.se sshd[80455]: /etc/ssh/sshd_config line 144: Directive 'Subsystem' is not allowed within a Match block

Comment 4 Linn 2022-05-02 12:27:30 CEST

Removing the acceptance criteria that warnings only should be shown if the user have altered sshd_config for thinlinc. No warnings were added, instead we log an error message as well as a traceback if this function throws an exception.

Comment 8 Linn 2022-05-02 14:08:54 CEST

Tested the acceptance criteria on RHEL 8:

> * There should be no alteration of any of the existing contents in /etc/ssh/sshd_config
There is not. Tested both 1) UTF-8 system, sshd_config in UTF-8, and 2) UTF-8 system, sshd_config in latin-1.

                       1) |  2)
File with markers      ✓  |  ✓
File without markers   ✓  |  ✓

I tried changing the username 'smör' from UTF-8 to Latin-1, by changing the encoding of /etc/passwd to latin-1, to see if such a username was correctly written to sshd_config. However, the user need to have a session for the username to be written in sshd_config, and I did not manage to log in with 'smör' in the wrong encoding. However, I did test that the username could be retrieved the way we do it without causing errors:
> >>> import pwd
> >>> pwd.getpwuid(1002).pw_name
> 'sm\udcf6r'

> * Any errors related to /etc/ssh/sshd_config should be gracefully handled, i.e. not cause crashes for vsmagent.
Tested the case described in comment 0, this does not cause a crash or any logging to the log. Also did not see anything odd in the log when testing the acceptance criteria above,

>  - These errors should also be logged to ease trouble shooting.
We write a traceback to the log when encountering an error, but since the error catching is more future proofing than anything else, I did not see any errors here.


Also updated the documentation to clarify that the ThinLinc specific markers have to be added at the end of sshd_config, and added release notes. 

Waiting for the Jenkins build to go through before marking as resolved.

Comment 9 Samuel Mannehed 2022-05-04 08:31:32 CEST

Using the "iconv" command in the initial comment I was able to reproduce this on Fedora 35 using 4.14.0.

After upgrading to server build 2605 I can verify that the bug is fixed. There are no errors in vsmagent.log and the session is started normally.

The new code looks good and so do the release notes.

Comment 10 Samuel Mannehed 2022-05-04 11:57:07 CEST

Tested on Fedora 35.