Hostnames 32+ characters long broke SSH authentication forwarding for me

Forums / NoMachine for Linux / Hostnames 32+ characters long broke SSH authentication forwarding for me

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • #28862
    DanielCarringtonHPE
    Participant

    Server environment:
    CentOS Linux release 7.6.1810 (Core)
    Linux kernel: 3.10.0-957.21.3.el7.x86_64
    MATE desktop environment: mate-session 1.16.1
    NX 6.7.6
    NX directory: /usr/NX
    Value of UNIX_PATH_MAX on my system (and basically everyone else’s): 108

     

    Player environment: any; Windows 10 + NX 6.11.2 was used

     

    I was able to overcome the issues in KB article ID AR12M00868 by changing some MATE desktop settings so that the SSH_AUTH_SOCK environment set by nxnode.bin was used throughout the desktop environment.
    The steps I did to fix my SSH_AUTH_SOCK environment were:
    – run mate-session-properties and disable the “SSH Key Agent”
    – run gsettings set org.mate.session gnome-compat-startup “[‘smproxy’]”
    – disconnect my current NX session and start a new one with SSH “Forward authentication” enabled

    Then, I verified that my SSH_AUTH_SOCK environment was working as expected:
    – open a new mate-terminal
    – type: echo $SSH_AUTH_SOCK
    /usr/NX/var/log/node/C-badly-long-subdomain.example.com-1001-12345678901234567890123456789012/sshAgentSocket

    This result so far is expected.

    This value for SSH_AUTH_SOCK is set by nxnode.bin and points to the sshAgentSocket in the NX session directory.

    However, note that the fully-qualified domain name is 32 characters long.

     

    To reproduce the problem, I did:
    – run: strace -e trace=connect -o ssh-connect.trace.txt ssh localhost

    I expected this to succeed without prompting for a password.
    However, it does not succeed, if the domain is 32 characters long or longer.
    The last few lines in ssh-connect.trace.txt after this is run (before the SIGINT from the Ctrl-C I used to kill it) are:

    —–

    connect(3, {sa_family=AF_INET, sin_port=htons(22), sin_addr=inet_addr(“127.0.0.1”)}, 16) = 0
    connect(3, {sa_family=AF_INET6, sin6_port=htons(22), inet_pton(AF_INET6, “::1”, &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0
    connect(3, {sa_family=AF_INET6, sin6_port=htons(22), inet_pton(AF_INET6, “::1″, &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0
    connect(4, {sa_family=AF_LOCAL, sun_path=”/usr/NX/var/log/node/C-badly-long-subdomain.example.com-1001-12345678901234567890123456789012/sshAgentSocke”}, 110) = -1 ENOENT (No such file or directory)

    —–

    Running “ssh -v localhost” produces the error message amid its output:
    —–

    debug1: pubkey_prepare: ssh_get_authentication_socket: No such file or directory

    —–

    But clearly, the SSH_AUTH_SOCK environment variable has a correct value.
    “ls -l $SSH_AUTH_SOCK” succeeds.

    However, looking closely at the filename in the failing connect() system call shows that the last character was truncated from the SSH_AUTH_SOCK pathname. This is because UNIX_PATH_MAX is 108 characters; considering a trailing \0 to terminate the string, UNIX domain sockets cannot have pathnames longer than 107 characters. My SSH_AUTH_SOCK value is 108 characters long because of my host’s long domain name.

    Look closely at the sun_path given to the last connect() call to see that it ends in “sshAgentSocke”, missing the final t in Socket, indicating that its value has been truncated.

    As such, SSH authentication forwarding is broken for me.

     

    Changing my domain name is not feasible because of corporate domain naming standards. Recompiling the kernel and all software I have installed would be needed in order to increase UNIX_PATH_MAX, and that is also not feasible. What can be done in order to fix SSH authentication forwarding for me and for other hostnames 32 characters or longer? Changing my NX connection settings to connect by IPv4 address instead of by hostname did not shorten the SSH_AUTH_SOCK value either.

     

    #28871
    brotech
    Participant

    Hello,

    this seems to be SSH limitation rather then NX, anyway You can change #UserNXDirectoryPath in node configuration file and this way shorten path a little.

    #28885
    DanielCarringtonHPE
    Participant

    Hi,
    The sshAgentSocket path isn’t in the the ~/.nx/ UserNXDirectoryPath, it’s in the ServerRoot; for me, /usr/NX. That can’t really be shortened too much.

    #
    # ServerRoot: The top of the directory tree under which the server's
    # configuration, error, and log files are kept.
    #
    # Do not add a slash at the end of the directory path. If you point
    # ServerRoot at a non-local disk, be sure to point the LockFile directive
    # at a local disk. If you wish to share the same ServerRoot for multiple
    # nxhtd daemons, you will need to change at least LockFile and PidFile.
    #
    ServerRoot "/usr/NX"
    

    An example sshAgentSocket path is:
    /usr/NX/var/log/node/C-badly-long-subdomain.example.com-1001-12345678901234567890123456789012/sshAgentSocket

    It’s not an SSH limitation; it’s a Linux kernel limitation; UNIX_PATH_MAX is a defined constant compiled into the Linux kernel.

    I would like for NX to produce shorter session directory names so that the authentication forwarding functionality would work.

    #28887
    brotech
    Participant

    Hello,
    there is also in node configuration file
    /usr/NX/etc/node.cfg
    a key:

    #
    # Specify hostname for the NoMachine node.
    #
    NodeName testname

    please set here something short and it will be used instead of long domain name.

    Regards

Viewing 4 posts - 1 through 4 (of 4 total)

This topic was marked as solved, you can't post.