Bug 5363

hum, same one as bug 5137 ?

Keywords: (none) => NEEDINFO

Probably, but he hit it only by re-installation. I report it is killing all active SSH connections during restart. Such situation is not acceptable in any decent distribution.

OK, iirc updating and reinstall is the same for urpmi. I will add a note

*** This bug has been marked as a duplicate of bug 5137 ***

Status: NEW => RESOLVED
Resolution: (none) => DUPLICATE

This is not a dupe.

Far more likely is that you have UsePAM=no in your sshd config.

We only support UsePAM=yes.

This is set automatically in our SSH package and there will be a release note added regarding this. For now I've added it to the errata, but it might get moved to a more appropriate place.

This will not affect mga1 to mga2 upgrades over SSH, but it would be wise to configure UsePAM=yes before upgrade anyway.

CC: (none) => mageia
Resolution: DUPLICATE => FIXED

reopen then

Keywords: NEEDINFO => (none)
Status: RESOLVED => REOPENED
Resolution: FIXED => (none)
Assignee: bugsquad => misc

No I changed the resolution to "fixed", not dupe (tho' as commented in the other bug, that was a little overzealous as it probably could be considered a dupe as the other bug was a least half about this issue!). This one is fixed as per my previous comment and the openssh-server changelog entry:

- Enable UsePAM by default (needed to prevent killing all SSH connections on service restart mga#5137)

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED

/me a bit slow today sorry

Hitting this myself. I don't recall changing the setting in the original config file from mga1, updated to cauldron, but I see an .rpmnew with the "yes" setting. Editing my config lets me restart the service and not get kicked out (the second time).

CC: (none) => stewbintn

(In reply to comment #8)
> Hitting this myself. I don't recall changing the setting in the original config
> file from mga1, updated to cauldron, but I see an .rpmnew with the "yes"
> setting. Editing my config lets me restart the service and not get kicked out
> (the second time).

Same here in a Cauldron server installed from beta1 dual-arch. Every update that has involved ssh has dropped connection. 
The "yes" was in a rpmnew file - not the running config.

CC: (none) => zen25000

As stated previously, I don't think messing with peoples configs is a good idea. It could open up security issues or similar due to pam configs suddenly being activated. I think it should just be something we mention in the release notes. Anyone "sysadminy" enough to want to enable SSH server should be the kind of person to read release notes and check for rpmnew files.

@Colin Gutherie: Now you expect people who never had to deal with such problems (every other distro have UsePAM yes by default) to look for reason in Release Notes? I have 10+ years of experience administering Linux systems, yet never even though about looking for cause of such unexpected behaviour in there. What I did I simply opened bugzilla, as this looks like bug and nothing else. To read .rpmnew and look for what's different there is another outrageous idea as many people are used to fact that almost every distribution have virtually the same default configuration and I am only tuning what I require to be changed. Your argument that SSH is only for "experienced admins" is invalid as well.

(In reply to comment #11)
> @Colin Gutherie: Now you expect people who never had to deal with such problems
> (every other distro have UsePAM yes by default) to look for reason in Release
> Notes? 

No, I expect people to read the release notes *before* upgrading. I would never even consider upgrading my distro without reading release notes to know whether or not the changes in the new version suit my needs.


> I simply opened bugzilla, as this looks like bug and nothing else. To
> read .rpmnew and look for what's different there is another outrageous idea.

Whenever I upgrade I always resolve the differences in the rpmnew files. It's standard practice as far as I'm concerned. Any sysadmin who does not do this can expect problem in one way or another as a result.

> many people are used to fact that almost every distribution have virtually the
> same default configuration and I am only tuning what I require to be changed.

Our *default* configuration is fine. What you are advocating here is that for upgrades we automatically adjust an administrators config file to expose a new method of authentication that is available as a network service? I'm sorry but I cannot do that without considering the security implications. What if the admin has adjusted his pam.d/system-auth because he wants to allow logins at certain times of day without passwords (pam_happyhour) - this means that we've automatically opened the machine to exploitation by making automatic adjustments. Sure this isn't particularly likely, but I would certainly not be happy as a sysadmin if some change like this was done automatically without my consent. For every bug report saying we should have done it, there will be one saying we shouldn't. We simply cannot win here. Documenting such changes in the release notes is still IMO the correct thing to do.

> Your argument that SSH is only for "experienced admins" is invalid as well.

OK, so your average user will be stung by the problem because they do subsequent upgrades with urpmi over ssh from a remote machine... yeah my grandmother does this every weekend. Please keep things in perspective.

What I mentioned in 5137:

 You should modify SPEC file for new openssh-server rpm with some macro (I
am not good with specs, so will not give example) that will first run rpm -Qf
/etc/ssh/sshd_config and if it finds file to be identical with standard
installation, file should be replaced with new fixed config file. As for now it
creates .rpmnew file.

That's IMHO best solution for this problem. In this case people who have not modified their default configuration in SSH will have SSH working as expected just after update - for me it sounds like Win-Win situation ;)

> Your argument that SSH is only for "experienced admins" is invalid as well.

My father, who never had any experience with Linux before is using Mageia1 now, he is happy with it, and I have spent some time teaching him how to update his system, sometimes he does that from 300km away via SSH - so I am not making assumptions here, I am just talking based on experience. You seem to be perfect developer for Debian - always know everything better than your users...

(In reply to comment #13)
> What I mentioned in 5137:
> 
>  You should modify SPEC file for new openssh-server rpm with some macro (I
> am not good with specs, so will not give example) that will first run rpm -Qf
> /etc/ssh/sshd_config and if it finds file to be identical with standard
> installation, file should be replaced with new fixed config file. As for now it
> creates .rpmnew file.
> 
> That's IMHO best solution for this problem. In this case people who have not
> modified their default configuration in SSH will have SSH working as expected
> just after update - for me it sounds like Win-Win situation ;)

That seems like a reasonable option, however I believe msec may modify the sshd config depending on security level, so this may not be 100% reliable. Certainly it could catch some (most) cases however. I will look into doing this.

> > Your argument that SSH is only for "experienced admins" is invalid as well.
> 
> My father, who never had any experience with Linux before is using Mageia1 now,
> he is happy with it, and I have spent some time teaching him how to update his
> system, sometimes he does that from 300km away via SSH - so I am not making
> assumptions here, I am just talking based on experience.

So you should also teach him to take heed of the warnings issued by urpmi about .rpmnew files and teach him how to compare them in order to resolve any differences.

You wouldn't teach a child to ride a bike but not tell them that the red light at an intersection means to stop - arming people with only part of the information they need is a dangerous game generally. We should not ban the use of traffic lights just because some people don't learn all they need should we?

> You seem to be perfect
> developer for Debian - always know everything better than your users...

I'll chose to ignore any personal insult under the surface there. I also think you have zero basis on which to form any opinion of myself. You are being quite selfish in view of the problem and have not addressed the fact that I consider my approach the safer one from a security perspective. You may disagree with that but I'd rather you used your reasons for disagreeing in any discussion that resorting to some kind of pointless rhetoric.

I never said that this macro I mentioned will solve 100% problems, I stated that it will solve problems of users who have not modified their configs - for me sounds as safe approach.

Off-Topic: Anyone knows any good documentation for msec except from source code? I never used msec due to lack of it's documentation - and it is a shame, because from what I have seen it may be very nice tool.

End Off-Topic.

'So you should also teach him to take heed of the warnings issued by urpmi about
.rpmnew files and teach him how to compare them in order to resolve any
differences.'

I had no need to do so with Mandriva before - in the end he is just update-aware desktop user, who knows how to use SSH, not system administrator - if there are more serious problems he calls me - so your traffic lights example is again missed one IMHO.
You can't expect that people who use Mageia will have knowledge of system administrators - they rarely have any knowledge about bash, yet to speak of administration, and rpmnew files.

Sorry if I insulted you - did not mean, just wanted to point out, that you should be more open to hear users, in the end they are your testers, and they are ones who promotes and uses this distro - or maybe I am wrong about that?