# openssh and elogind

## dmpogo

I would like to understand how ssh and elogind  interacts, and how to decrease this interaction to minimum.

Recently I tried to ssh (key based, no password) into my office desktop, which I have not touched since May,  and ssh seemingly hanged. I almost thought the machine is down,  but ping went through.   

Fortunately I did not kill the hanging ssh, but let it be, and approx after 45 sec - 1 min it suddenly connected.   Looking at the log I saw elogind  related timeouts on dbus, which took that time.   I never ran elogind as boot service on that machine, but it was launched on as needed basis by display manager, and one instance of elogind was running.      When I killed it, and launched  elogind as service, timeouts disappeared, and ssh connects quickly.

I would like to try to avoid ssh connection to have anything to do with elogind, if possible.   I do have several systems which rely on automated ssh key-based connection between my computers, and I do not want to be

in a position when they'll start timing out here and there (actually in this instance, original problem was timing out of my script for vnc connection via ssh tunneling, which was few steps away from the real problem).

Could somebody point me to appropriate info ?Last edited by dmpogo on Mon Sep 14, 2020 1:09 am; edited 1 time in total

----------

## Hu

Based on how elogind interaction works for local login, it's almost certain that this is being done through a PAM module that applies to sshd, and interacts with elogind as part of its operation.  On that assumption, I would start with reading /etc/pam.d/sshd.  That file may include other PAM configurations.  Follow those recursively to find references to elogind.  If the reference is in one of the included files, and you only want to modify sshd and not other login flows, you may need to restructure the files or do other special handling to implement the bypass selectively.

----------

## dmpogo

 *Hu wrote:*   

> Based on how elogind interaction works for local login, it's almost certain that this is being done through a PAM module that applies to sshd, and interacts with elogind as part of its operation.  On that assumption, I would start with reading /etc/pam.d/sshd.  That file may include other PAM configurations.  Follow those recursively to find references to elogind.  If the reference is in one of the included files, and you only want to modify sshd and not other login flows, you may need to restructure the files or do other special handling to implement the bypass selectively.

 

The only reference to elogind among nested included files that I tracked  is in system-auth,  which has

-session        optional        pam_elogind.so

so given that elogind is optional, and even with -session  system does not log if it is missing,  it seems my problems were more because I had elogind instance running (and somehow misbehaving), rather than not having it at all ?

----------

## Hu

That seems plausible.  What happens if you have no elogind processes running at all when the user tries to log in via ssh?

----------

## dmpogo

 *Hu wrote:*   

> That seems plausible.  What happens if you have no elogind processes running at all when the user tries to log in via ssh?

 

Yep, I felt I should check this before writing, but had no time at that moment.  Indeed,   works quickly as  it should with no active elogind. Cool

----------

## figueroa

Re: "I would like to try to avoid ssh connection to have anything to do with elogind, if possible."

Why?

----------

## Hu

If I had to guess, because there is no apparent reason that it should need to, and because the symptoms in the bad case were fairly disruptive.  If elogind offered some benefit to ssh connections, maybe the failure mode would be worth risking.  As is, it appears to have no upside and plenty of potential downside, even if that downside is (so far) apparently limited to systems that are configured in the "wrong" way.

----------

## dmpogo

 *figueroa wrote:*   

> Re: "I would like to try to avoid ssh connection to have anything to do with elogind, if possible."
> 
> Why?

 

One a general level I do not like systems to be coupled unless this is needed.   

On a more specific level,   for me ssh is one the most basic service,  the one that should die last.   When (almost) everything died,  I still want to login remotely. 

For me, in its role, it is just above tcp/ip stack itself.

Elogind is a convenience froth on top.    Basically, to be able to insert your usb stick with proper permissions.   Lower level services should not rely in their function on higher level one.

My situation at the end was not as bad as I feared for a moment (that ssh actually requires functioning elogind), but it is still a bit disconcerting that a rogue elogind process managed to

shoot done some ssh invocations.

----------

## Tony0945

dmpogo,  I agree.

----------

## jesnow

How was this issue resolved in the end? elogind is needed for other things, so it's no good if it blocks ssh.

----------

## Hu

According to the original post, the method of running elogind was changed to one which apparently works without timeouts.  Additionally, there is the option of configuring sshd not to use elogind at all, though that may have unwanted side effects, as elogind would then be unaware of users who connected over ssh.  Whether this unawareness would lead to negative consequences for the users is not known.

----------

## dmpogo

 *jesnow wrote:*   

> How was this issue resolved in the end? elogind is needed for other things, so it's no good if it blocks ssh.

 

As a first step I killed the running elogind and launched elogind as a boot service.   SSH worked fine.   However, next, seeing thhat elogind is actually only an optional module in pam hierarchy,  I have 

checked the hunch that if I stop elogind, ssh should still work. And it did.

So the problem seems to have been  a misbehaving  elogind instance that was running (launched some time ago by sddm),   rather than the lack of elogind.

----------

