Description of problem: cannot sftp into a mga3 box. ssh is no problem This is the error message: subsystem request failed on channel 0 Couldn't read packet: Connection reset by peer Version-Release number of selected component (if applicable): How reproducible: Every time on all of my boxes. Worked in mga1 and 2 Steps to Reproduce: 1.open Konsole or shell 2.sftp user@192.168.0.xxx 3.enter password 4. get above error message Reproducible: Steps to Reproduce:
Not a general bug since this works for me with two accounts, one using an ssh key, the other using a password. The client I sftp'd from is Mageia 2. Check for any relevant log entries on the server. If you can track down a definitive cause for this issue, and it turns out to be a real bug, you can reopen.
Status: NEW => RESOLVEDResolution: (none) => WORKSFORME
I do not think it's resolved. It may be filed under the wrong package. It needs this in the /etc/ssh/sshd_conf file # override default of no subsystems Subsystem sftp /usr/lib/ssh/sftp-server Drakwizard should take care of this when configuring it.
This is already set during install of openssh-server.
CC: (none) => mageia
Indeed, that Subsystem line is there by default. You don't need to use drakwizard to set up an SSH server, just install openssh-server. If you are doing something with drakwizard and it's removing that line, you can make this a bug against drakwizard.
OK, let's assign this to drakwizard.
Source RPM: ssh server => DrakwizardStatus: RESOLVED => REOPENEDResolution: WORKSFORME => (none)
Did you test first or just assign?
I did test this on three boxes before filing, two were upgraded and one was a fresh install. I agree, if you just install the openssh-server by itself then the lines are there. But it's much more convenient to use the drakwizard in MCC, it will install the openssh-server. Otherwise you need to know the name of it. It looks as if the Drakwizard completely rewrites the sshd_conf file.
Summary: cannot sftp into a mga3 box => cannot sftp into a mga3 box if ssh is set up with drakwizardHardware: x86_64 => AllAssignee: bugsquad => derekjenn
It appears the GlueConf module used by the wizards reads the existing config file, adds the new values to the end, then filters out duplicate keys saving the last key. HostKey is listed 3 times in the original sshd_config, the last being: HostKey /etc/ssh/ssh_host_dsa_key The ssh server didn't seem to use the dsa key on my machine. The only key that allowed the client to authenticate was the rsa key. You can test by changing the 'd' to an 'r' in the top line after running the wizard. A quick workaround (not a fix) would be to list the rsa key last in the openssh-server package.
CC: (none) => warrendiogenese
I think the problem is caused because GlueConf is called to read the current configuration before the openssh-server package is installed so it reads a null configuration, and the new config becomes simply what was set in the wizard. If openssh-server is installed before drakwizard is run, then the Subsystem ftp command survives intact.
When the wizard creates a new sshd_config instance, it reads the config file: http://bit.ly/1awJe3y (Lines 79,80) Then calls set_uniq ( http://bit.ly/18PiHrq ) which deletes all preceding atoms with duplicate keys. Each atom consists of a key, value and all comments and blank lines preceding it. That included the header for the first key in the original config. Of course openssh-server needs to be installed before the wizard can be used. It needs to read sshd_config from that package.
Created attachment 4341 [details] Ensure openssh-server is installed before reading config This patch fixes the problem with sftp described in the original bug report. It ensures that the openssh-server package is installed before reading the sshd.config file. When testing uninstall openssh-server and remove /etc/ssh/sshd.config.rpmsave and /etc/ssh/sshd.config before running drakwizard. William. With respect to the problem with rsa/dsa hostkeys. You are correct that GlueConf does not allow more than one instance of a configuration parameter of the same name, and that sshd.config allows the HostKey parameter to appear more than once. That is a different issue to the original bug report, and should be a new bug report. It would have to be fixed I think in perl-Libconf, and may be just a case of removing that set_uniq line.
Created attachment 4342 [details] Code fragments for comment 10 links Marja reminded me the links in comment 10 are temporary, so here is the code they refer too. I don't believe these are separate issues. After running the ssh-server drakwizard, I could no longer login using sftp. The wizard removed the HostKey needed for the client to authenticate itself. If you add the keys back that it removed and ran wizard again, they would be removed again, breaking sftp login (unless the rsa key is listed last).
(In reply to William Murphy from comment #12) > I don't believe these are separate issues. After running the ssh-server > drakwizard, I could no longer login using sftp. The wizard removed the > HostKey needed for the client to authenticate itself. I have performed a number of tests. a/ Regardless of whether HostKey is set to dsa or rsa I can ssh or sftp into the server. The only difference is that the dsa or rsa key gets added to the ~/.ssh/known_hosts file in the client. b/ If I change the HostKey parameter to dsa from rsa (or vice versa) then it is necessary to remove the entry in the known_hosts file before I can successfully connect. (this is to be expected) c/ If I use public key authentication it makes no difference if I am using an rsa public key and the HostKey is dsa I remain convinced we have two different problems here:- 1/ If openssh-server is not already installed when drakwizard is run, then it will discard the entire sshd.config file including the Subsystem sftp /usr/lib/ssh/sftp-server line and break sftp BTW: Ignore my patch. It is ineffective. I will do another one. 2/ If openssh-server IS already installed before running drakwizard, then it will remove the HostKey line relating to rsa which will prevent clients connecting with either ssh or sftp if they have previously already connected using the rsa HostKey (the workaround is to remove the entry in known_hosts)
I'll try to explain my thinking better. I didn't think to try this without openssh-server installed. After installing openssh-server and logging in successfully using sftp, I made a copy of the working /etc/ssh/sshd_config, then tried the openssh-server wizard. I ran the wizard in beginner and export mode and tried a number of setting, then compared the working copy of sshd_config to the new one. All the new setting were at the bottom of the new config and the beginning comments, along with: HostKey /etc/ssh/ssh_host_key HostKey /etc/ssh/ssh_host_rsa_key Had been removed from sshd_config and I could no longer login using sftp. After adding both entries back to the sshd_config, I could login using sftp again. Then I tried removing all but one entry for each of these and attempted to login using sftp, only the rsa key allowed the client to login, which tells me the client was using protocol version 2 to authenticate itself. Then I started looking at the perl modules involved and noticed that duplicate keys in any given configuration block were being dropped. In this case, the first 2 HostKey entries. I concluded that after running the wizard, all but one of the HostKey entries will be dropped. If the client uses a protocol not supported by the remaining HostKey entry in sshd_config, authenication will fail. In this case, the sftp client tried to authenticate itself using protocol 2 (rsa), which was no longer supported after running the wizard. That entry had been dropped from the config file.
(In reply to William Murphy from comment #14) > I am not disagreeing with you. Your account corresponds with what I am seeing myself apart from your remark in Commment 8 >The ssh server didn't seem to use the dsa key on my machine. The only key that >allowed the client to authenticate was the rsa key. I am able to log in when the Hostkey is set to use dsa key. There must be something specific about your configuration that is stopping the dsa key working (permissions maybe?) I have done some more investigating and have established that commenting out the set_uniq line in GlueConf does work, and will result in a sshd.conf where the HostKey lines survive intact. However I still think you should raise a separate bug report on that because it is not the problem described by Thomas in Comments 2 and 7, and because it needs to be fixed in perl-Libconf. I am reluctant to do anything to perl-Libconf because it has a maintainer, and I do not know what unintended consequences might result if I modified a library. As for this bug report I have a revised patch to fix it.
Created attachment 4343 [details] Better patch
Attachment 4341 is obsolete: 0 => 1
Created attachment 4344 [details] fix typo
Attachment 4343 is obsolete: 0 => 1
Is anybody working on this bug or should we close it again?
It looks like Derek proposed a patch. If someone can test and confirm that it works, we'll also need someone to submit it, as Derek seems to have left.
Why has this not been assigned to the maintainer? $ mgarepo maintdb get drakwizard tv
You can change it yourself too..
Keywords: (none) => PATCHCC: (none) => derekjennAssignee: derekjenn => thierry.vignaudSource RPM: Drakwizard => drakwizard
Thierry just had a baby (not physically, but you know what I mean) so I guess the code for this lives in GIT now and any of us *should* be able to commit the patch. Thomas, can you try to commit it yourself? https://wiki.mageia.org/en/How_to_use_Git Colin is the best person to ask if there's trouble with Git.
I will try. I never used git, so don't scold me if something goes wrong.
These changes have already been implemented in mga4 and current cauldron. I have checked it out in cauldron and the fix works. The patch also allows DSA authentication. I have submited the package to mga3 updates_testing: drakwizard-3.9.2-1.1.mga3.src.rpm drakwizard-3.9.2-1.1.mga3.noarch.rpm drakwizard-base-3.9.2-1.1.mga3.noarch.rpm Assigning it to QA
CC: (none) => thomasAssignee: thierry.vignaud => qa-bugs
Validating this. See the discussion in the QA meeting: http://meetbot.mageia.org/mageia-qa/2014/mageia-qa.2014-07-31-19.02.log.html#l-30 The advisory still needs to be uploaded. The packages are listed in Comment 24. The advisory could read: "If drakwizard was used to set up the SSH service, it was incorrectly disabling SFTP functionality. This has been corrected." Please push this to core/updates for Mageia 3.
Keywords: PATCH => validated_updateCC: (none) => sysadmin-bugs
Advisory uploaded.
CC: (none) => remiWhiteboard: (none) => advisory
Made sure it installs in Mageia 3 32bit.
Whiteboard: advisory => advisory MGA3-32-OK
An update for this issue has been pushed to Mageia Updates repository. http://advisories.mageia.org/MGAA-2014-0157.html
Status: REOPENED => RESOLVEDResolution: (none) => FIXED