Bug 2316431
| Summary: | ProFTPD Update Breaks ssh-agent SFTP Authentication | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora EPEL | Reporter: | ICHIKAWA Tomohiro <ichikawa-t12> | ||||||
| Component: | proftpd | Assignee: | Paul Howarth <paul> | ||||||
| Status: | NEW --- | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | unspecified | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | epel8 | CC: | ingvar, paul | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | Type: | Bug | |||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
ICHIKAWA Tomohiro
2024-10-04 08:09:38 UTC
Could you possibly try some debug tracing to compare the updated version with the previous version to see where things are different, and what exactly the error is? http://www.proftpd.org/docs/howto/Tracing.html I Took a look at the code and couldn't see any obvious interaction between the change in the update (which relates to processing configuration) and the ssh-agent functionality. Created attachment 2052282 [details]
v1.3.6e-6
Created attachment 2052283 [details]
v1.3.6e-7
ssh-agent may not be relevant. I conducted a comparison test between v1.3.6e-6 and v1.3.6e-7 in a different environment. Without using ssh-agent, I tried connecting directly with the sftp command. v1.3.6e-6 successfully connected, while v1.3.6e-7 failed. I'm attaching the logs for each. From a quick look at the logs, it appears that v1.3.6e-6 showed signs of opening the authorized_key file, but v1.3.6e-7 showed no signs of opening it at all. |