[Bug 2641] Add systemd notify code to to track running server
https://bugzilla.mindrot.org/show_bug.cgi?id=2641 git...@kalvdans.no-ip.org changed: What|Removed |Added CC||git...@kalvdans.no-ip.org -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3438] env var that is SetEnv'ed multiple times in the same SetEnv directive, is sent/printed several times
https://bugzilla.mindrot.org/show_bug.cgi?id=3438 git...@kalvdans.no-ip.org changed: What|Removed |Added CC||git...@kalvdans.no-ip.org -- You are receiving this mail because: You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3379] Config parser only allows SetEnv once
https://bugzilla.mindrot.org/show_bug.cgi?id=3379 git...@kalvdans.no-ip.org changed: What|Removed |Added CC||git...@kalvdans.no-ip.org -- You are receiving this mail because: You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3605] Tracking bug for OpenSSH 9.5
https://bugzilla.mindrot.org/show_bug.cgi?id=3605 Bug 3605 depends on bug 3602, which changed state. Bug 3602 Summary: Limit artificial delay to some reasonable limit https://bugzilla.mindrot.org/show_bug.cgi?id=3602 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching the reporter of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3602] Limit artificial delay to some reasonable limit
https://bugzilla.mindrot.org/show_bug.cgi?id=3602 Damien Miller changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Damien Miller --- Committed and will be in OpenSSH 9.5, due in a few months. -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3605] Tracking bug for OpenSSH 9.5
https://bugzilla.mindrot.org/show_bug.cgi?id=3605 Darren Tucker changed: What|Removed |Added Depends on||3602 Referenced Bugs: https://bugzilla.mindrot.org/show_bug.cgi?id=3602 [Bug 3602] Limit artificial delay to some reasonable limit -- You are receiving this mail because: You are watching the reporter of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3602] Limit artificial delay to some reasonable limit
https://bugzilla.mindrot.org/show_bug.cgi?id=3602 Darren Tucker changed: What|Removed |Added Blocks||3605 Referenced Bugs: https://bugzilla.mindrot.org/show_bug.cgi?id=3605 [Bug 3605] Tracking bug for OpenSSH 9.5 -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3602] Limit artificial delay to some reasonable limit
https://bugzilla.mindrot.org/show_bug.cgi?id=3602 Darren Tucker changed: What|Removed |Added Attachment #3717|ok?(dtuc...@dtucker.net)| Flags|| Attachment #3717|0 |1 is obsolete|| Attachment #3724||ok+ Flags|| --- Comment #2 from Darren Tucker --- Created attachment 3724 --> https://bugzilla.mindrot.org/attachment.cgi?id=3724&action=edit Seems reasonable. Patch can be simplified a little, though. -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3602] Limit artificial delay to some reasonable limit
https://bugzilla.mindrot.org/show_bug.cgi?id=3602 Damien Miller changed: What|Removed |Added CC||d...@mindrot.org, ||dtuc...@dtucker.net Attachment #3717||ok?(dtuc...@dtucker.net) Flags|| --- Comment #1 from Damien Miller --- Comment on attachment 3717 --> https://bugzilla.mindrot.org/attachment.cgi?id=3717 A proposed patch This looks sensible to me. -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3355] no-touch-required flag not restored from hardware token
https://bugzilla.mindrot.org/show_bug.cgi?id=3355 daemonh...@nullcore.com changed: What|Removed |Added CC||daemonh...@nullcore.com -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2817] Add support for PKCS#11 URIs (RFC 7512)
https://bugzilla.mindrot.org/show_bug.cgi?id=2817 daemonh...@nullcore.com changed: What|Removed |Added CC||daemonh...@nullcore.com --- Comment #7 from daemonh...@nullcore.com --- This would be helpful on multiple platforms for me (Windows, FreeBSD, Linux). I'm willing to assist with regression testing if I can help expedite this patch landing. Is there are committer that is willing to pickup and merge ? -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3572] ssh-agent refused operation when using FIDO2 with -O verify-required
https://bugzilla.mindrot.org/show_bug.cgi?id=3572 --- Comment #8 from bluebird090...@proton.me --- The path /usr/libexec/ does not exist on arch linux but /usr/lib/ssh/x11-ssh-askpass is available However I did manage to get the pin entry to work on arch using the x11-ssh-askpass package on a fresh arch installation. Your instructions also worked on a fresh Debian Bookworm after installing the ssh-askpass-gnome package and I can use the agent with the fido2 key and pin verification. In both cases I had to define SSH_ASKPASS first. Eventually I found out that the reason ssh-askpass didn't work initially on my arch setup was because I had this set in my bashrc: export SSH_AUTH_SOCK="$XDG_RUNTIME_DIR/ssh-agent.socket" while I also had this systemd service: [Unit] Description=SSH key agent [Service] Type=simple Environment=SSH_AUTH_SOCK=%t/ssh-agent.socket ExecStart=/usr/bin/ssh-agent -D -t 1h -a $SSH_AUTH_SOCK [Install] WantedBy=default.target Removing this export from my bashrc results in ssh-askpass successfully requesting the pin. (And I'm very confused why that is) Note that SSH_AUTH_SOCK is available as environment variable in both cases, but setting it in bashrc seems to prevent askpass from working for some reason. To conclude, setting SSH_ASKPASS allows the agent to successfully request the pin when using fido2 keys with verify-required -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3599] How to scan for keys when sshd server has fips enabled?
https://bugzilla.mindrot.org/show_bug.cgi?id=3599 --- Comment #8 from Shreenidhi Shedi --- Hi Damien Miller, Is there anything pending from my end? Please let me know. -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3608] ssh version is different with sshd version
https://bugzilla.mindrot.org/show_bug.cgi?id=3608 --- Comment #7 from yata...@gmail.com --- (In reply to Darren Tucker from comment #6) > Patch applied and will be in the next release. Thanks. Nice. Thank you! -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3605] Tracking bug for OpenSSH 9.5
https://bugzilla.mindrot.org/show_bug.cgi?id=3605 Darren Tucker changed: What|Removed |Added Depends on||3608 Referenced Bugs: https://bugzilla.mindrot.org/show_bug.cgi?id=3608 [Bug 3608] ssh version is different with sshd version -- You are receiving this mail because: You are watching the assignee of the bug. You are watching the reporter of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3605] Tracking bug for OpenSSH 9.5
https://bugzilla.mindrot.org/show_bug.cgi?id=3605 Bug 3605 depends on bug 3608, which changed state. Bug 3608 Summary: ssh version is different with sshd version https://bugzilla.mindrot.org/show_bug.cgi?id=3608 What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching the reporter of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3608] ssh version is different with sshd version
https://bugzilla.mindrot.org/show_bug.cgi?id=3608 Darren Tucker changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED Blocks||3605 --- Comment #6 from Darren Tucker --- Patch applied and will be in the next release. Thanks. Referenced Bugs: https://bugzilla.mindrot.org/show_bug.cgi?id=3605 [Bug 3605] Tracking bug for OpenSSH 9.5 -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3605] Tracking bug for OpenSSH 9.5
https://bugzilla.mindrot.org/show_bug.cgi?id=3605 Bug 3605 depends on bug 3604, which changed state. Bug 3604 Summary: Building OpenSSH fails with zlib1.3 installed https://bugzilla.mindrot.org/show_bug.cgi?id=3604 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching the reporter of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3604] Building OpenSSH fails with zlib1.3 installed
https://bugzilla.mindrot.org/show_bug.cgi?id=3604 Damien Miller changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||d...@mindrot.org -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3608] ssh version is different with sshd version
https://bugzilla.mindrot.org/show_bug.cgi?id=3608 Damien Miller changed: What|Removed |Added Attachment #3723||ok+ Flags|| -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3608] ssh version is different with sshd version
https://bugzilla.mindrot.org/show_bug.cgi?id=3608 --- Comment #5 from yata...@gmail.com --- (In reply to Darren Tucker from comment #2) > This is about the output of "sshd -V" not the version in the > protocol output: > > There's two version identifiers in version.h, the base OpenSSH > version and the -portable version: > > #define SSH_VERSION "OpenSSH_9.4" > #define SSH_PORTABLE"p1" > #define SSH_RELEASE SSH_VERSION SSH_PORTABLE > > Upstream (OpenBSD) only uses SSH_VERSION. > > ssh.c uses SSH_RELEASE (the full version) and has for a long, long > time > (https://github.com/openssh/openssh-portable/commit/ > 2aa6d3cfce738f57c31ae676e11399382bd5660e): > > case 'V': > fprintf(stderr, "%s, %s\n", > SSH_RELEASE, SSH_OPENSSL_VERSION); > > When sshd -V was added in OpenBSD it used SSH_VERSION (the base > version), and when it was synced into -portable this was brought > over without change > ((https://github.com/openssh/openssh-portable/commit/ > 7d17ea151c0b2519f023bd9cc7f141128833ac47): > > case 'V': > fprintf(stderr, "%s, %s\n", > SSH_VERSION, SSH_OPENSSL_VERSION); > > I contend sshd -V should match ssh -V behaviour. Yeah, I saw this version logic in ssh.c sshd.c, and I very agreed with you, this two version should matched. -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3608] ssh version is different with sshd version
https://bugzilla.mindrot.org/show_bug.cgi?id=3608 --- Comment #4 from yata...@gmail.com --- (In reply to Damien Miller from comment #1) > sshd doesn't print the portable patch version in its output because > it is irrelevant - portable patch releases don't change the protocol. Is this means when openssh has a major release, like 9.2 -> 9.3, the protocol has changed, so sshd version changed too? -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3608] ssh version is different with sshd version
https://bugzilla.mindrot.org/show_bug.cgi?id=3608 Darren Tucker changed: What|Removed |Added Attachment #3723||ok?(d...@mindrot.org) Flags|| --- Comment #3 from Darren Tucker --- Created attachment 3723 --> https://bugzilla.mindrot.org/attachment.cgi?id=3723&action=edit include portable version in sshd -V output -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3608] ssh version is different with sshd version
https://bugzilla.mindrot.org/show_bug.cgi?id=3608 Darren Tucker changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX |--- CC||dtuc...@dtucker.net --- Comment #2 from Darren Tucker --- This is about the output of "sshd -V" not the version in the protocol output: There's two version identifiers in version.h, the base OpenSSH version and the -portable version: #define SSH_VERSION "OpenSSH_9.4" #define SSH_PORTABLE"p1" #define SSH_RELEASE SSH_VERSION SSH_PORTABLE Upstream (OpenBSD) only uses SSH_VERSION. ssh.c uses SSH_RELEASE (the full version) and has for a long, long time (https://github.com/openssh/openssh-portable/commit/2aa6d3cfce738f57c31ae676e11399382bd5660e): case 'V': fprintf(stderr, "%s, %s\n", SSH_RELEASE, SSH_OPENSSL_VERSION); When sshd -V was added in OpenBSD it used SSH_VERSION (the base version), and when it was synced into -portable this was brought over without change ((https://github.com/openssh/openssh-portable/commit/7d17ea151c0b2519f023bd9cc7f141128833ac47): case 'V': fprintf(stderr, "%s, %s\n", SSH_VERSION, SSH_OPENSSL_VERSION); I contend sshd -V should match ssh -V behaviour. -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3572] ssh-agent refused operation when using FIDO2 with -O verify-required
https://bugzilla.mindrot.org/show_bug.cgi?id=3572 --- Comment #7 from Damien Miller --- (In reply to bluebird090909 from comment #6) > I didn't have ssh-askpass installed either, but even after > installing it and using the steps above, the result was the same. Well, you didn't follow my instructions so that's not surprising. > Running on Arch Linux: > > sudo pacman -S x11-ssh-askpass > env SSH_ASKPASS=/usr/lib/ssh/x11-ssh-askpass ssh-agent $SHELL -l That's not the right path. I had the correct path in the instructions in comment #5. Try replacing /usr/lib/ssh/x11-ssh-askpass with /usr/libexec/openssh/x11-ssh-askpass. > Shouldn't entering the pin on the terminal work as well? It works > during key registration at least, so I don't get why ssh-askpass > would be required? Because ssh-agent is a daemon process that isn't connected to the terminal. -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3608] ssh version is different with sshd version
https://bugzilla.mindrot.org/show_bug.cgi?id=3608 Damien Miller changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW |RESOLVED CC||d...@mindrot.org --- Comment #1 from Damien Miller --- sshd doesn't print the portable patch version in its output because it is irrelevant - portable patch releases don't change the protocol. -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3608] New: ssh version is different with sshd version
https://bugzilla.mindrot.org/show_bug.cgi?id=3608 Bug ID: 3608 Summary: ssh version is different with sshd version Product: Portable OpenSSH Version: 9.3p2 Hardware: amd64 OS: Linux Status: NEW Severity: normal Priority: P5 Component: sshd Assignee: unassigned-b...@mindrot.org Reporter: yata...@gmail.com Created attachment 3722 --> https://bugzilla.mindrot.org/attachment.cgi?id=3722&action=edit version info when i installed openssh-9.3p2 openssh-server-9.3p2 openssh-clients-9.3p2, then i check the binary version, ssh has OpenSSH_9.3p2 and sshd has OpenSSH_9.3. Why these two binary version is not same? -- You are receiving this mail because: You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3572] ssh-agent refused operation when using FIDO2 with -O verify-required
https://bugzilla.mindrot.org/show_bug.cgi?id=3572 --- Comment #6 from bluebird090...@proton.me --- I didn't have ssh-askpass installed either, but even after installing it and using the steps above, the result was the same. Running on Arch Linux: sudo pacman -S x11-ssh-askpass env SSH_ASKPASS=/usr/lib/ssh/x11-ssh-askpass ssh-agent $SHELL -l ssh-add ~/.ssh/id_ed25519_sk Identity added: /home/user/.ssh/id_ed25519_sk ssh-add -T ~/.ssh/id_ed25519_sk.pub Agent signature failed for /home/user/.ssh/id_ed25519_sk.pub: agent refused operation Shouldn't entering the pin on the terminal work as well? It works during key registration at least, so I don't get why ssh-askpass would be required? -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3572] ssh-agent refused operation when using FIDO2 with -O verify-required
https://bugzilla.mindrot.org/show_bug.cgi?id=3572 --- Comment #5 from Damien Miller --- This looks like it is a problem with how Fedora is running/configuring ssh-agent. You can test this using something like: sudo yum install openssh-askpass env SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass ssh-agent $SHELL -l ssh-add ~/.ssh/id_ed25519_sk ssh-add -T ~/.ssh/id_ed25519_sk.pub -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3572] ssh-agent refused operation when using FIDO2 with -O verify-required
https://bugzilla.mindrot.org/show_bug.cgi?id=3572 --- Comment #4 from xspielinbox+mind...@protonmail.com --- I do not have openssh-askpass installed, but I do have pinentry, pinentry-gnome3, gnome-keyring and gnome-keyring-pam installed. $SSH_ASKPASS and SSH_AGENT_PID seem to be unset. $SSH_AUTH_SOCK is set to: /run/user/1000/keyring/ssh I am using the default configuration of Fedora Workstation what SSH-Agent / SSH-Askpass is concerned. I do get graphical dialogs to unlock my password-protected SSH-Keys without any issues. After running ssh-add an additional process is running: /usr/bin/ssh-agent -D -a /run/user/1000/keyring/.ssh I hope this helped. I apologize, if it was useless information. I am not that familiar with ssh-agent/ssh-askpass workings. If you need any other information please let me know. I will do my best to answer. -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3549] Tracking bug for OpenSSH 9.4
https://bugzilla.mindrot.org/show_bug.cgi?id=3549 Damien Miller changed: What|Removed |Added Depends on||3579 Referenced Bugs: https://bugzilla.mindrot.org/show_bug.cgi?id=3579 [Bug 3579] OpenSSH trims last character of fixed-lenght buffers received from the pkcs11 providers providing users with inaccurate information -- You are receiving this mail because: You are watching the assignee of the bug. You are watching the reporter of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3549] Tracking bug for OpenSSH 9.4
https://bugzilla.mindrot.org/show_bug.cgi?id=3549 Bug 3549 depends on bug 3579, which changed state. Bug 3579 Summary: OpenSSH trims last character of fixed-lenght buffers received from the pkcs11 providers providing users with inaccurate information https://bugzilla.mindrot.org/show_bug.cgi?id=3579 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching the assignee of the bug. You are watching the reporter of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3579] OpenSSH trims last character of fixed-lenght buffers received from the pkcs11 providers providing users with inaccurate information
https://bugzilla.mindrot.org/show_bug.cgi?id=3579 Damien Miller changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Blocks||3549 CC||d...@mindrot.org --- Comment #1 from Damien Miller --- This was fixed in 6958f00acf3b9 and released in OpenSSH 9.4 Referenced Bugs: https://bugzilla.mindrot.org/show_bug.cgi?id=3549 [Bug 3549] Tracking bug for OpenSSH 9.4 -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3572] ssh-agent refused operation when using FIDO2 with -O verify-required
https://bugzilla.mindrot.org/show_bug.cgi?id=3572 Damien Miller changed: What|Removed |Added CC||d...@mindrot.org --- Comment #3 from Damien Miller --- Is your ssh-agent configured to use $SSH_ASKPASS? The agent should display a PIN entry dialog for verify-required keys if the askpass program is available. -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3572] ssh-agent refused operation when using FIDO2 with -O verify-required
https://bugzilla.mindrot.org/show_bug.cgi?id=3572 --- Comment #2 from bluebird090...@proton.me --- A workaround for this issue is to disable the ssh-agent for the relevant connections using the option -o IdentityAgent=none Alternatively add this to your ~/.ssh/config Host myserver.tld IdentityAgent none -- You are receiving this mail because: You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3606] no-touch-required option refused by server
https://bugzilla.mindrot.org/show_bug.cgi?id=3606 bluebird090...@proton.me changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #2 from bluebird090...@proton.me --- no-touch-required was missing in the authorized_keys file. Sorry for the noise. -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3607] Redundant "Confirm user presence"
https://bugzilla.mindrot.org/show_bug.cgi?id=3607 Damien Miller changed: What|Removed |Added Resolution|--- |WONTFIX CC||d...@mindrot.org Status|NEW |RESOLVED --- Comment #1 from Damien Miller --- Unfortunately some of these can't be avoided as it's impossible to perform some FIDO operations without requiring the user confirm user presence by touching their key. Which operations? We have no way of knowing prior to attempting them, so we've taken the approach of attempting erring on the side of redundantly warning the user rather than risking things hanging while waiting for the user to touch without notice -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3606] no-touch-required option refused by server
https://bugzilla.mindrot.org/show_bug.cgi?id=3606 Damien Miller changed: What|Removed |Added CC||d...@mindrot.org --- Comment #1 from Damien Miller --- Did you specify no-touch-required when you added the key to your authorized_keys file? -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3607] New: Redundant "Confirm user presence"
https://bugzilla.mindrot.org/show_bug.cgi?id=3607 Bug ID: 3607 Summary: Redundant "Confirm user presence" Product: Portable OpenSSH Version: 9.4p1 Hardware: All OS: Linux Status: NEW Severity: enhancement Priority: P5 Component: ssh Assignee: unassigned-b...@mindrot.org Reporter: bluebird090...@proton.me Connecting with a security key results in the following behavior: $ ssh tester@testserver Confirm user presence for key ED25519-SK SHA256:7eZ... Enter PIN for ED25519-SK key /home/user/.ssh/id_ed25519_sk-test: (Pin is entered) Confirm user presence for key ED25519-SK SHA256:7eZ... (Authenticator touched) To clarify: After initiating the connection, I get the following two lines immediately: Confirm user presence for key ED25519-SK SHA256:7eZ... Enter PIN for ED25519-SK key /home/user/.ssh/id_ed25519_sk-test: I then enter the PIN and get the next line: Confirm user presence for key ED25519-SK SHA256:7eZ... Then I touch the device (once) and am logged in I never need to touch the device twice to login. The key was generated with the following: ssh-keygen -t ed25519-sk -O resident -O verify-required -O application=ssh:test Both Client and Server are running Arch with OpenSSH 9.4 Used Security Key: Nitrokey 3, Firmware version: v1.5.0 -- You are receiving this mail because: You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3606] New: no-touch-required option refused by server
https://bugzilla.mindrot.org/show_bug.cgi?id=3606 Bug ID: 3606 Summary: no-touch-required option refused by server Product: Portable OpenSSH Version: 9.4p1 Hardware: All OS: Linux Status: NEW Severity: normal Priority: P5 Component: ssh Assignee: unassigned-b...@mindrot.org Reporter: bluebird090...@proton.me Using a security key with the option no-touch-required is always refused by the server with the following message: error: public key ED25519-SK SHA256:2Rw. signature for user from 10.0.2.2 port 35614 rejected: user presence (authenticator touch) requirement not met To reproduce: 1. generate key: ssh-keygen -t ed25519-sk -O resident -O verify-required -O no-touch-required -O application=ssh:test 2. add key to authorized_keys on target server 3. Connect to server with -o IdentityAgent=none (required as workaround for bug 3572) connection is refused (no further information on client side) 4. find the above mentioned error message in the journal log Both Client and Server are running Arch with OpenSSH 9.4 Used Security Key: Nitrokey 3, Firmware version: v1.5.0 -- You are receiving this mail because: You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3603] ssh clients can't communicate with server with default cipher when fips is enabled at server end
https://bugzilla.mindrot.org/show_bug.cgi?id=3603 --- Comment #20 from Dmitry Belyavskiy --- I see several problems with the proposed patch. It resolves the case when the run-time and build-time OpenSSL version differs in capabilities. The problem is it relies on legacy OpenSSL API that contradicts the initial request (FIPS compatibility). Also EC curve detection uses the API OpenSSL considers legacy (and so not FIPS-compliant). And from the FIPS perspective, all NIST curves supported by OpenSSH are allowed. -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3603] ssh clients can't communicate with server with default cipher when fips is enabled at server end
https://bugzilla.mindrot.org/show_bug.cgi?id=3603 --- Comment #19 from Shreenidhi Shedi --- >Shreenidhi Shedi, > Just use PKIX-SSH instead - could be used with OpenSSL, RedHad and Solaris > FIPS validated OpenSSL libraries. Hi Roumen, Thanks for the input. I'm not sure what pkix-ssh is, can you share some more info please? -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3603] ssh clients can't communicate with server with default cipher when fips is enabled at server end
https://bugzilla.mindrot.org/show_bug.cgi?id=3603 Roumen Petrov changed: What|Removed |Added CC||bugtr...@roumenpetrov.info --- Comment #18 from Roumen Petrov --- So, world knows hot to detect what is available in FIPS mode. More then 15 years OpenBSD ream refuse to do simple detection. It is expected to continue in next decades. Shreenidhi Shedi, Just use PKIX-SSH instead - could be used with OpenSSL, RedHad and Solaris FIPS validated OpenSSL libraries. Regards, Roumen -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3603] ssh clients can't communicate with server with default cipher when fips is enabled at server end
https://bugzilla.mindrot.org/show_bug.cgi?id=3603 Damien Miller changed: What|Removed |Added Attachment #3720|0 |1 is obsolete|| --- Comment #17 from Damien Miller --- Created attachment 3721 --> https://bugzilla.mindrot.org/attachment.cgi?id=3721&action=edit probe ciphers, MACs and KEX -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3603] ssh clients can't communicate with server with default cipher when fips is enabled at server end
https://bugzilla.mindrot.org/show_bug.cgi?id=3603 --- Comment #16 from Damien Miller --- I don't think that does what we want - that function seems to allow going from a string name to an EVP but we already have the EVP and just want to check that it is enabled by OpenSSL without having to arrange everything EVP_*_init() wants. -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3603] ssh clients can't communicate with server with default cipher when fips is enabled at server end
https://bugzilla.mindrot.org/show_bug.cgi?id=3603 Dmitry Belyavskiy changed: What|Removed |Added CC||dbely...@redhat.com --- Comment #15 from Dmitry Belyavskiy --- In case of OpenSSL 3.0+ EVP_fetch* methods can be used for this purpose. -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3603] ssh clients can't communicate with server with default cipher when fips is enabled at server end
https://bugzilla.mindrot.org/show_bug.cgi?id=3603 --- Comment #14 from Damien Miller --- No, I don't think we've decided that yet. -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3605] Tracking bug for OpenSSH 9.5
https://bugzilla.mindrot.org/show_bug.cgi?id=3605 Darren Tucker changed: What|Removed |Added Keywords||meta -- You are receiving this mail because: You are watching the assignee of the bug. You are watching the reporter of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3605] Tracking bug for OpenSSH 9.5
https://bugzilla.mindrot.org/show_bug.cgi?id=3605 Darren Tucker changed: What|Removed |Added Depends on||3604 Referenced Bugs: https://bugzilla.mindrot.org/show_bug.cgi?id=3604 [Bug 3604] Building OpenSSH fails with zlib1.3 installed -- You are receiving this mail because: You are watching the reporter of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3604] Building OpenSSH fails with zlib1.3 installed
https://bugzilla.mindrot.org/show_bug.cgi?id=3604 Darren Tucker changed: What|Removed |Added Blocks||3605 CC||dtuc...@dtucker.net --- Comment #1 from Darren Tucker --- Thanks for the report. This should be fixed by: https://github.com/openssh/openssh-portable/commit/cb4ed12ffc332d1f72d054ed92655b5f1c38f621 Note that if you apply this yourself you'll need to run "autoreconf" to rebuild configure before running it. Snapshots and releases have this already done. Referenced Bugs: https://bugzilla.mindrot.org/show_bug.cgi?id=3605 [Bug 3605] Tracking bug for OpenSSH 9.5 -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3605] New: Tracking bug for OpenSSH 9.5
https://bugzilla.mindrot.org/show_bug.cgi?id=3605 Bug ID: 3605 Summary: Tracking bug for OpenSSH 9.5 Product: Portable OpenSSH Version: -current Hardware: All OS: All Status: NEW Severity: normal Priority: P5 Component: Miscellaneous Assignee: unassigned-b...@mindrot.org Reporter: dtuc...@dtucker.net -- You are receiving this mail because: You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3604] New: Building OpenSSH fails with zlib1.3 installed
https://bugzilla.mindrot.org/show_bug.cgi?id=3604
Bug ID: 3604
Summary: Building OpenSSH fails with zlib1.3 installed
Product: Portable OpenSSH
Version: 9.4p1
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P5
Component: Build system
Assignee: unassigned-b...@mindrot.org
Reporter: fab...@wenks.ch
Running on macOS 13.5 (Ventura) with MacPorts, but based on the version
check this may affect all OS versions as soon as zlib 1.3 is installed.
I did the upgrades with 'port upgrade outdated', zlib 1.2.13_0 -> 1.3_0
and OpenSSH 9.3p2_0 -> 9.4p1_0 and the update of zlib was done before
openssh:
# port installed | grep '^ zlib'
zlib @1.2.13_0 requested_variants='' platform='darwin 22'
archs='x86_64' date='2023-07-21T19:42:11+0200'
zlib @1.3_0 (active) requested_variants='' platform='darwin 22'
archs='x86_64' date='2023-08-18T18:40:38+0200'
Building OpenSSH 9.4p1_0 failed with this error:
checking for deflate in -lz... yes
checking for possibly buggy zlib... yes
configure: error: *** zlib too old - check config.log ***
Your reported zlib version has known security problems. It's possible
your
vendor has fixed these problems without changing the version number.
If you
are sure this is the case, you can disable the check by running
"./configure --without-zlib-version-check".
If you are in doubt, upgrade zlib to version 1.2.3 or greater.
See http://www.gzip.org/zlib/ for details.
More relevant details out of the config.log:
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
It was created by OpenSSH configure Portable, which was
generated by GNU Autoconf 2.71. Invocation command line was
$ ./configure --prefix=/opt/local --with-ssl-dir=/opt/local
--sysconfdir=/opt/local/etc/ssh --with-privsep-path=/var/empty
--with-md5-passwords --with-pid-dir=/opt/local/var/run --with-pam
--mandir=/opt/local/share/man --with-zlib=/opt/local
--without-kerberos5 --with-libedit --with-pie
--with-xauth=/opt/local/bin/xauth --with-ldns --with-audit=bsm
--with-keychain=apple
[...]
configure:10755: checking for zlib
configure:10763: result: yes
configure:10768: checking for zlib.h
configure:10768: /opt/local/bin/clang-mp-15 -c -pipe -Os
-isysroot/Applications/
Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.s
dk -arch x86_64 -pipe -Wunknown-warning-option -Qunused-arguments -Wall
-Wpointe
r-arith -Wuninitialized -Wsign-compare -Wformat-security
-Wsizeof-pointer-memacc
ess -Wno-pointer-sign -Wno-unused-result -Wmisleading-indentation
-Wbitwise-inst
ead-of-logical -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -ftrapv
-fzero-call-used
-regs=used -fno-builtin-memset -fstack-protector-strong
-I/opt/local/include -I/
opt/local/include -DBROKEN_STRNVIS=1 -D__APPLE_SANDBOX_NAMED_EXTERNAL__
-D__APPL
E_API_STRICT_CONFORMANCE -D__APPLE_LAUNCHD__
-isysroot/Applications/Xcode.app/Co
ntents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.sdk
conftest.
c >&5
configure:10768: $? = 0
configure:10768: result: yes
[...]
configure:10809: result: yes
configure:10871: checking for possibly buggy zlib
configure:10911: /opt/local/bin/clang-mp-15 -o conftest -pipe -Os
-isysroot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.sdk
-arch x86_64 -pipe -Wunknown-warning-option -Qunused-arguments -Wall
-Wpointer-arith -Wuninitialized -Wsign-compare -Wformat-security
-Wsizeof-pointer-memaccess -Wno-pointer-sign -Wno-unused-result
-Wmisleading-indentation -Wbitwise-instead-of-logical
-fno-strict-aliasing -D_FORTIFY_SOURCE=2 -ftrapv
-fzero-call-used-regs=used -fno-builtin-memset -fstack-protector-strong
-I/opt/local/include -I/opt/local/include -DBROKEN_STRNVIS=1
-D__APPLE_SANDBOX_NAMED_EXTERNAL__ -D__APPLE_API_STRICT_CONFORMANCE
-D__APPLE_LAUNCHD__
-isysroot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.sdk
-L/opt/local/lib -L/opt/local/lib -Wl,-headerpad_max_install_names
-Wl,-search_paths_first
-Wl,-syslibroot,/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.sdk
-arch x86_64 -fstack-protector-strong conftest.c -lz >&5
configure:10911: $? = 0
configure:10911: ./conftest
configure:10911: $? = 1
configure: program exited with status 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "OpenSSH"
| #define PACKAGE_TARNAME "openssh"
| #define PACKAGE_VERSION "Portable"
| #define PACKAGE_STRING "OpenSSH Portable"
| #define PACKAGE_BUGREPORT "openssh-unix-...@mindrot.org"
[...]
| #define HAVE_BASENAME 1
| #define WITH_ZLIB 1
| #define HAVE_LIBZ 1
| /* end confdefs.h. */
|
| #include
| #include
| #include
|
| int
| main (void)
| {
|
| int a=0, b=0, c=0, d=0, n, v;
| n = sscanf(ZLIB_VERSION, "%d.%d.%d.%d", &a, &b, &c, &d);
|
[Bug 3603] ssh clients can't communicate with server with default cipher when fips is enabled at server end
https://bugzilla.mindrot.org/show_bug.cgi?id=3603 --- Comment #13 from Shreenidhi Shedi --- Hi Damien, Thanks for being patient and understanding the problem. So if I have understood it right, upstream is intending to fix this issue and we can expect a fix in the future releases of openssh. -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3603] ssh clients can't communicate with server with default cipher when fips is enabled at server end
https://bugzilla.mindrot.org/show_bug.cgi?id=3603 --- Comment #12 from Damien Miller --- Created attachment 3720 --> https://bugzilla.mindrot.org/attachment.cgi?id=3720&action=edit runtime probing of ciphers > You can try this in your setup as well, enable openssl fips in server, use > latest openssh server and try connecting from a client with no ciphers > mentioned. ok, you're putting OpenSSL in FIPS mode and not patching OpenSSH. You've then created a situation where the OpenSSL you're using is behaving differently to the OpenSSL that OpenSSH was compiled with, and currently OpenSSH is not in a position to detect this. Changing this basically requires that OpenSSH do runtime probing of all cryptography to see whether something has changed underneath it. This patch is an example of how we might approach this. Maybe it helps your case? It certainly isn't complete - we'd need to do effectively the same thing for MACs, public key algorithms and key agreement algorithms too since I bet some of those could be disabled by OpenSSL's FIPS support too. The patch could probably be simplified if there's a simpler way to query whether OpenSSL supports a particular algorithm. In the meantime, if you're changing your crypto library to disable particular algorithms, then you need to *manually* change your ssh_config and sshd_config to match. -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3603] ssh clients can't communicate with server with default cipher when fips is enabled at server end
https://bugzilla.mindrot.org/show_bug.cgi?id=3603 --- Comment #11 from Shreenidhi Shedi --- Created attachment 3719 --> https://bugzilla.mindrot.org/attachment.cgi?id=3719&action=edit client connection log -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3603] ssh clients can't communicate with server with default cipher when fips is enabled at server end
https://bugzilla.mindrot.org/show_bug.cgi?id=3603 Shreenidhi Shedi changed: What|Removed |Added Resolution|INVALID |--- Status|RESOLVED|REOPENED --- Comment #10 from Shreenidhi Shedi --- I have to reopen this. I think the ticket is closed with misunderstanding. Please check the logs I attached and try it once in your machine. -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3603] ssh clients can't communicate with server with default cipher when fips is enabled at server end
https://bugzilla.mindrot.org/show_bug.cgi?id=3603 --- Comment #9 from Shreenidhi Shedi --- Hi Damien, thanks for your response. Please ignore the details on the patch I provided. I'm currently talking about newer openssh with no patch included, check this spec. https://github.com/vmware/photon/blob/5.0/SPECS/openssh/openssh.spec I'm using 9.3p2 here and no patch and don't intend to add it as well. Now question is, if I take latest openssh and deploy it on both client and server and enable fips in server, will client be able to communicate with the server? I am attaching the log for this scenario but with a slightly lower version of server and client. PTAL. -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3603] ssh clients can't communicate with server with default cipher when fips is enabled at server end
https://bugzilla.mindrot.org/show_bug.cgi?id=3603 --- Comment #8 from Shreenidhi Shedi --- Created attachment 3718 --> https://bugzilla.mindrot.org/attachment.cgi?id=3718&action=edit sshd-config and sshd_config Adding sshd config & client log both. Doing ssh to localhost after enabling fips. -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3603] ssh clients can't communicate with server with default cipher when fips is enabled at server end
https://bugzilla.mindrot.org/show_bug.cgi?id=3603 Damien Miller changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #7 from Damien Miller --- Darren has stated several times what the problem is: your FIPS modifications are simply broken. Refer to his answer in comment 1. We're not in a position to fix this because we didn't write the FIPS patch that you're using. You need to contact its authors if you want support - we cannot help beyond pointing out how it is broken, which Darren has already done. -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3603] ssh clients can't communicate with server with default cipher when fips is enabled at server end
https://bugzilla.mindrot.org/show_bug.cgi?id=3603 --- Comment #6 from Shreenidhi Shedi --- Sorry for the confusion. The patch I mentioned #1 is in Photon 3.0. Ignore the patch related info I provided, that's something we are doing in 3.0 version only. Now I'm hitting this issue in Photon 5.0 where we are using 9.3p2. In this we just use what's given by upstream with mostly default settings. In this our cipher list is, exactly this https://github.com/openssh/openssh-portable/blob/master/myproposal.h#L59 And we are hitting this issue. You can try this in your setup as well, enable openssl fips in server, use latest openssh server and try connecting from a client with no ciphers mentioned. -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3603] ssh clients can't communicate with server with default cipher when fips is enabled at server end
https://bugzilla.mindrot.org/show_bug.cgi?id=3603 --- Comment #5 from Darren Tucker --- (In reply to Shreenidhi Shedi from comment #4) > Can you please point out what we are missing? here is our spec file. > > https://github.com/vmware/photon/blob/5.0/SPECS/openssh/openssh.spec > > Thanks a lot for your quick response and inputs. Like I mentioned > earlier, we are not modifying things much; do we need to enable any > config during configure stage? In comment#1 you said: "We did something like in PhotonOS 3.0: https://github.com/vmware/photon/blob/3.0/SPECS/openssh/openssh-7.8p1-fips.patch"; but now you're pointing to a repo whos SPEC file doesn't contain anything like that patch. It also specifies an OpenSSH version that corresponds to *neither* of the versions you mentioned in comment#1. You are applying a FIPS patch to OpenSSH or are you not? Are you building a stock(ish) OpenSSH against a FIPS OpenSSL? Exactly which versions are you talking about and exactly which modifications are you making to it? -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3603] ssh clients can't communicate with server with default cipher when fips is enabled at server end
https://bugzilla.mindrot.org/show_bug.cgi?id=3603 --- Comment #4 from Shreenidhi Shedi --- (In reply to Darren Tucker from comment #3) > (In reply to Shreenidhi Shedi from comment #2) > > > Your server is lying about what ciphers it supports > > > > This is the concern I have here. We are not explicitly setting these > > in sshd_config and using defaults. Why does default cipher list show > > chacha20 when it is not supporting it? > > Because your modifications to the server are insufficient. They > should remove it but don't. Can you please point out what we are missing? here is our spec file. https://github.com/vmware/photon/blob/5.0/SPECS/openssh/openssh.spec Thanks a lot for your quick response and inputs. Like I mentioned earlier, we are not modifying things much; do we need to enable any config during configure stage? -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3603] ssh clients can't communicate with server with default cipher when fips is enabled at server end
https://bugzilla.mindrot.org/show_bug.cgi?id=3603 --- Comment #3 from Darren Tucker --- (In reply to Shreenidhi Shedi from comment #2) > > Your server is lying about what ciphers it supports > > This is the concern I have here. We are not explicitly setting these > in sshd_config and using defaults. Why does default cipher list show > chacha20 when it is not supporting it? Because your modifications to the server are insufficient. They should remove it but don't. -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3603] ssh clients can't communicate with server with default cipher when fips is enabled at server end
https://bugzilla.mindrot.org/show_bug.cgi?id=3603 --- Comment #2 from Shreenidhi Shedi --- > Your server is lying about what ciphers it supports This is the concern I have here. We are not explicitly setting these in sshd_config and using defaults. Why does default cipher list show chacha20 when it is not supporting it? Or is it the suggested method from upstream that all downstream instances should set cipherlist explicitly omitting chacha20 when fips is enabled? This list is coming from here: https://github.com/openssh/openssh-portable/blob/master/myproposal.h#L59 I'm certain that we are not adding any cipher list explicitly. -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3603] ssh clients can't communicate with server with default cipher when fips is enabled at server end
https://bugzilla.mindrot.org/show_bug.cgi?id=3603 --- Comment #1 from Darren Tucker --- (In reply to Shreenidhi Shedi from comment #0) [...] > When fips is enabled at server end and server has the following > cipher set, > > ``` > root@phdev:~ $ sshd -T | grep ciphers > ciphers > chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr, > aes128-...@openssh.com,aes256-...@openssh.com This indicates your FIPS modifications to the server are incorrect. The server seems to be advertising the chacha20 cipher but seems unable or unwilling to actually use it. If it's not going to support them it should not offer them, and if the server's config explicitly includes it then it should either refuse to start or remove them and log a warning. > root@phdev:~ $ rpm -q openssh > openssh-9.1p1-10.ph5.x86_64 (this happens with 9.4p1 as well) > ``` > > The handshake with client starts with chacha20-poly1305 and this > cipher is not fips complaint. > > I'm not sure what the intention was but in this commit: > https://github.com/openssh/openssh-portable/commit/ > a22b9ef21285e81775732436f7c84a27bd3f71e0 > > chacha20 cipher was promoted. That was the intent, and it's fine. Simplifying a bit, the way it's supposed to work is that the client picks the cipher from the list that the server offers that it likes most. Your server is lying about what ciphers it supports, and when the client takes it up on its offer for chacha20, it doesn't work (from your description, probably the server is aborting, but you'd have to check your server logs). Fix your server and it should work fine. -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3603] ssh clients can't communicate with server with default cipher when fips is enabled at server end
https://bugzilla.mindrot.org/show_bug.cgi?id=3603 Shreenidhi Shedi changed: What|Removed |Added CC||d...@mindrot.org, ||dtuc...@dtucker.net -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3603] New: ssh clients can't communicate with server with default cipher when fips is enabled at server end
https://bugzilla.mindrot.org/show_bug.cgi?id=3603 Bug ID: 3603 Summary: ssh clients can't communicate with server with default cipher when fips is enabled at server end Product: Portable OpenSSH Version: 9.4p1 Hardware: All OS: Linux Status: NEW Severity: critical Priority: P5 Component: sshd Assignee: unassigned-b...@mindrot.org Reporter: ssh...@vmware.com Hi, This seems like a regression at first but there is a way to work around it. When fips is enabled at server end and server has the following cipher set, ``` root@phdev:~ $ sshd -T | grep ciphers ciphers chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com root@phdev:~ $ rpm -q openssh openssh-9.1p1-10.ph5.x86_64 (this happens with 9.4p1 as well) ``` The handshake with client starts with chacha20-poly1305 and this cipher is not fips complaint. I'm not sure what the intention was but in this commit: https://github.com/openssh/openssh-portable/commit/a22b9ef21285e81775732436f7c84a27bd3f71e0 chacha20 cipher was promoted. At the client end, "ssh user@IP" doesn't work and aborts almost immediately. To workaround this issue, we need to do: "ssh -c aes128-ctr user@IP" In place of aes128-ctr, we can use any other algo which is fips complaint (aes256-ctr, aes192-ctr etc). Expected result: ssh server should handle this gracefully. Possible solutions: 1. Change the cipher order in KEX_SERVER_ENCRYPT (myproposal.h) 2. Use the same order but tweak the cipher list at run time based on fips status in the system. We did something like in PhotonOS 3.0: https://github.com/vmware/photon/blob/3.0/SPECS/openssh/openssh-7.8p1-fips.patch But we are unsure about the issue this might cause. 3. Server should send a proper error message to client in this case showing some details on what went wrong; currently client simply aborts with zero info. 4. If fips is enabled and sshd_config has ciphers which are incompatible in fips mode, sshd should throw a warning and use the next available fips complaint cipher from the list. Even now, we can do the following in sshd_config, cipherlist aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com,chacha20-poly1...@openssh.com But we have to do it in all the server instances. I think this should be handled by server considering fips scenario. Please feel free to correct me if I'm wrong here. -- You are receiving this mail because: You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3602] New: Limit artificial delay to some reasonable limit
https://bugzilla.mindrot.org/show_bug.cgi?id=3602 Bug ID: 3602 Summary: Limit artificial delay to some reasonable limit Product: Portable OpenSSH Version: 9.4p1 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5 Component: sshd Assignee: unassigned-b...@mindrot.org Reporter: dbely...@redhat.com Created attachment 3717 --> https://bugzilla.mindrot.org/attachment.cgi?id=3717&action=edit A proposed patch Commit https://github.com/beldmit/openssh-portable/commit/e9d910b0289c820852f7afa67f584cef1c05fe95 introduced a randomized delay to avoid user enumeration timing attack. Unfortunately, in case of bad network it effectively doubles the time spent in the input_userauth_request (mostly presumably in PAM). So if PAM processing is really slow, it will cause huge delays - but if it is so slow, it's more difficult to perform the enumeration attack. The proposed patch removes the delay in case of "none" auth method as it is a dummy method and no information can be obtained from the delay and establishes a reasonable threshold to limit the delay. The patch is also available as https://github.com/openssh/openssh-portable/pull/429 -- You are receiving this mail because: You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3601] Cannot change password if no password is given
https://bugzilla.mindrot.org/show_bug.cgi?id=3601 Darren Tucker changed: What|Removed |Added CC||dtuc...@dtucker.net --- Comment #1 from Darren Tucker --- OpenSSH 8.1 was nearly four years ago. Can you reproduce it with the current version? A quick test with the current version works as expected. If this isn't what you're referring to, can you add some more specific reproduction steps? $ ssh-keygen -f tmp -N '' Generating public/private rsa key pair. Your identification has been saved in tmp Your public key has been saved in tmp.pub The key fingerprint is: [...] $ ssh-keygen -p -f tmp -N foo [...] Your identification has been saved with the new passphrase. $ ssh-keygen -p -f tmp -P foo -N '' [...] Your identification has been saved with the new passphrase. $ ssh-keygen -p -f tmp [...] Enter new passphrase (empty for no passphrase): foo Enter same passphrase again: foo Your identification has been saved with the new passphrase. -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3601] New: Cannot change password if no password is given
https://bugzilla.mindrot.org/show_bug.cgi?id=3601 Bug ID: 3601 Summary: Cannot change password if no password is given Product: Portable OpenSSH Version: 8.1p1 Hardware: 68k OS: Mac OS X Status: NEW Severity: enhancement Priority: P5 Component: ssh-keygen Assignee: unassigned-b...@mindrot.org Reporter: ab1...@gmail.com If you create a key with ssh-keygen without a password and try to add a password with `ssh-keygen -p`, the prompt will request old password and if no password is given, the prompt will return incorrect password. Obviously, if you input anything, the same prompt will be returned. -- You are receiving this mail because: You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3599] How to scan for keys when sshd server has fips enabled?
https://bugzilla.mindrot.org/show_bug.cgi?id=3599 --- Comment #7 from Shreenidhi Shedi --- Hi Damien Miller, Any inputs on when this will get merged? I mean when will this be a part of github repo? Thanks. -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3599] How to scan for keys when sshd server has fips enabled?
https://bugzilla.mindrot.org/show_bug.cgi?id=3599 --- Comment #6 from Shreenidhi Shedi --- Okay, that looks fine. I was expecting these new pointers to get freed programmatically, if we are delegating that job to system, that's fine too. Thanks for the response. -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3599] How to scan for keys when sshd server has fips enabled?
https://bugzilla.mindrot.org/show_bug.cgi?id=3599 --- Comment #5 from Damien Miller --- It won't until the program exits. It will be around for the life of the process because it's needed for the life of the process -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3599] How to scan for keys when sshd server has fips enabled?
https://bugzilla.mindrot.org/show_bug.cgi?id=3599 --- Comment #4 from Shreenidhi Shedi --- One query, take this for example. ``` macs = xstrdup(optarg + 5); ``` When will macs get freed? -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3599] How to scan for keys when sshd server has fips enabled?
https://bugzilla.mindrot.org/show_bug.cgi?id=3599 --- Comment #3 from Shreenidhi Shedi --- Awesome, yes. These additional changes makes this fix complete for now. Thanks a lot. -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3599] How to scan for keys when sshd server has fips enabled?
https://bugzilla.mindrot.org/show_bug.cgi?id=3599 Damien Miller changed: What|Removed |Added Attachment #3713|0 |1 is obsolete|| Attachment #3716||ok?(dtuc...@dtucker.net) Flags|| --- Comment #2 from Damien Miller --- Created attachment 3716 --> https://bugzilla.mindrot.org/attachment.cgi?id=3716&action=edit Options for MACs and KexAlgorithms too, document Thanks, I think you patch makes sense. This tweaks it a little, but also adds support for overriding some other things that might cause problems in restricted configurations (MACs and key-exchange algorithms), and documents them all in the ssh-keygen.8 manpage. -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3599] How to scan for keys when sshd server has fips enabled?
https://bugzilla.mindrot.org/show_bug.cgi?id=3599 Damien Miller changed: What|Removed |Added Attachment #3713|application/octet-stream|text/plain mime type|| Attachment #3713|0 |1 is patch|| -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3598] Dead lock of sshd and Defunct of sshd
https://bugzilla.mindrot.org/show_bug.cgi?id=3598 --- Comment #12 from Damien Miller --- > This seems like a bit too large of a change to go in so close to a release? oh sure, not proposing this for 9.4 but afterwards -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3598] Dead lock of sshd and Defunct of sshd
https://bugzilla.mindrot.org/show_bug.cgi?id=3598 --- Comment #11 from Darren Tucker --- Comment on attachment 3715 --> https://bugzilla.mindrot.org/attachment.cgi?id=3715 Really fixed diff >From 9f895491cc6a671fc49b9cda78edfe3801b0af74 Mon Sep 17 00:00:00 2001 >From: Damien Miller >Date: Fri, 4 Aug 2023 14:51:03 +1000 >Subject: [PATCH] logging of monitor process exits in listener This seems like a bit too large of a change to go in so close to a release? -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3598] Dead lock of sshd and Defunct of sshd
https://bugzilla.mindrot.org/show_bug.cgi?id=3598 Damien Miller changed: What|Removed |Added Attachment #3714|0 |1 is obsolete|| Attachment #3715||ok?(dtuc...@dtucker.net) Flags|| --- Comment #10 from Damien Miller --- Created attachment 3715 --> https://bugzilla.mindrot.org/attachment.cgi?id=3715&action=edit Really fixed diff This should fix the problems in the previous diff and simplifies things a little more. Child processes now signal that authentication was successful back to the listener, so it can stop tracking them. They do this by sending another char over the startup_pipe, in addition to the first one they send to signal they have received their rexec state. When the listener is so notified, it stops caring about the subprocess and frees up its slot so it doesn't count against MaxStartups. -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3236] multiple Subsystem options in sshd_config prevent sshd from starting
https://bugzilla.mindrot.org/show_bug.cgi?id=3236 Michael Yagliyan changed: What|Removed |Added CC||burnsmellfact...@gmail.com -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3598] Dead lock of sshd and Defunct of sshd
https://bugzilla.mindrot.org/show_bug.cgi?id=3598 Damien Miller changed: What|Removed |Added Attachment #3714|ok?(dtuc...@dtucker.net)| Flags|| --- Comment #9 from Damien Miller --- Comment on attachment 3714 --> https://bugzilla.mindrot.org/attachment.cgi?id=3714 Fixed diff actually, this diff has a big problem too: because it tracks all child processes in the same structure, and because the tracking logic is incorrect, it limits the _total_ number of concurrent sessions to MaxSessions and not just the number of _authenticating_ sessions :( -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3598] Dead lock of sshd and Defunct of sshd
https://bugzilla.mindrot.org/show_bug.cgi?id=3598 Damien Miller changed: What|Removed |Added Attachment #3711|ok?(dtuc...@dtucker.net)| Flags|| Attachment #3711|0 |1 is obsolete|| Attachment #3714||ok?(dtuc...@dtucker.net) Flags|| --- Comment #8 from Damien Miller --- Created attachment 3714 --> https://bugzilla.mindrot.org/attachment.cgi?id=3714&action=edit Fixed diff Revised diff that fixes a couple of logic errors and simplifies some code. -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3600] New: please make ssh-keygen symlink aware for proper handling of hosts removal in symlinked known_hosts
https://bugzilla.mindrot.org/show_bug.cgi?id=3600 Bug ID: 3600 Summary: please make ssh-keygen symlink aware for proper handling of hosts removal in symlinked known_hosts Product: Portable OpenSSH Version: 9.3p2 Hardware: amd64 OS: Linux Status: NEW Severity: enhancement Priority: P5 Component: ssh-keygen Assignee: unassigned-b...@mindrot.org Reporter: devz...@web.de apparently, if a known_hosts file is being symlinked, when using ssh-keygen -f -R hostname the reference to the symlinked file is being lost, as ssh-keygen is renaming the file and recreating it new not sure how to handle this issue correctly in proxmox otherwise, without makeing ssh-keygen symlink aware https://bugzilla.proxmox.com/show_bug.cgi?id=4252 -- You are receiving this mail because: You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3595] Configure.ac Check Header Versions
https://bugzilla.mindrot.org/show_bug.cgi?id=3595 --- Comment #4 from Darren Tucker --- (In reply to soup_79 from comment #3) > It is a gentoo based system. then why are you installing mixed library and header versions? I don't think we would be interested in relaxing the default checks as it adds yet another variable we may end up having to debug. If you want to force it you have the option to do so with --without-openssl-header-check. -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3599] How to scan for keys when sshd server has fips enabled?
https://bugzilla.mindrot.org/show_bug.cgi?id=3599 --- Comment #1 from Shreenidhi Shedi --- Created attachment 3713 --> https://bugzilla.mindrot.org/attachment.cgi?id=3713&action=edit attempt to fix. Tried fixing the issue. PTAL. I'm unaware of the development process in this project, so raised a github PR as well. https://github.com/openssh/openssh-portable/pull/424 -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3599] How to scan for keys when sshd server has fips enabled?
https://bugzilla.mindrot.org/show_bug.cgi?id=3599 Shreenidhi Shedi changed: What|Removed |Added CC||d...@mindrot.org, ||dtuc...@dtucker.net -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3599] New: How to scan for keys when sshd server has fips enabled?
https://bugzilla.mindrot.org/show_bug.cgi?id=3599 Bug ID: 3599 Summary: How to scan for keys when sshd server has fips enabled? Product: Portable OpenSSH Version: 9.3p2 Hardware: All OS: Linux Status: NEW Severity: critical Priority: P5 Component: ssh-keyscan Assignee: unassigned-b...@mindrot.org Reporter: ssh...@vmware.com Created attachment 3712 --> https://bugzilla.mindrot.org/attachment.cgi?id=3712&action=edit Server's sshd config Hi, I have an sshd server which is fips enabled and client is non fips. How to get the server public keys using ssh-keyscan in this case? I tried running keyscan in the server itself and even that is failing. ``` root@ph5dev:~ # ssh-keyscan localhost # localhost:22 SSH-2.0-OpenSSH_9.3 # localhost:22 SSH-2.0-OpenSSH_9.3 # localhost:22 SSH-2.0-OpenSSH_9.3 # localhost:22 SSH-2.0-OpenSSH_9.3 # localhost:22 SSH-2.0-OpenSSH_9.3 ``` This also returns nothing. The work around for this issue is, adding below line (or some other fips complaint cipher) to /etc/ssh/sshd_config ``` Ciphers aes128-ctr ``` AFAIK, nothing can be done from client side to make it work. Please let me know if there is anyway to get it working. Proposed solutions: - ssh-keyscan should use configs from /etc/ssh/ssh_config or $HOME/.ssh/config like ssh does - ssh-keyscan should accept "-c " arg to do negotiation with server. - A conf file of its own for ssh-keyscan. Ultimately, ssh-keyscan should work without any modifications in server and little or no change at client side. PFA for my server config. -- You are receiving this mail because: You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3566] Password expiry warning is printed multiple times when UsePAM is set to yes
https://bugzilla.mindrot.org/show_bug.cgi?id=3566 --- Comment #1 from Shreenidhi Shedi --- Probably the attached patch is incorrect, if you think this is a valid issue; I'll try to come up with a better solution and inputs welcome. -- Shedi -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3566] Password expiry warning is printed multiple times when UsePAM is set to yes
https://bugzilla.mindrot.org/show_bug.cgi?id=3566 Shreenidhi Shedi changed: What|Removed |Added CC||d...@mindrot.org -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3566] Password expiry warning is printed multiple times when UsePAM is set to yes
https://bugzilla.mindrot.org/show_bug.cgi?id=3566 Shreenidhi Shedi changed: What|Removed |Added CC||dtuc...@dtucker.net -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3595] Configure.ac Check Header Versions
https://bugzilla.mindrot.org/show_bug.cgi?id=3595 --- Comment #3 from soup...@hotmail.com --- It is a gentoo based system. -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 1975] Support for Match configuration directive to also include subsystems
https://bugzilla.mindrot.org/show_bug.cgi?id=1975 --- Comment #2 from Damien Miller --- Implemented in https://github.com/djmdjm/openssh-wip/pull/23 -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3598] Dead lock of sshd and Defunct of sshd
https://bugzilla.mindrot.org/show_bug.cgi?id=3598 Damien Miller changed: What|Removed |Added Attachment #3711||ok?(dtuc...@dtucker.net) Flags|| --- Comment #7 from Damien Miller --- Created attachment 3711 --> https://bugzilla.mindrot.org/attachment.cgi?id=3711&action=edit implement LoginGraceTime logging in listener This removes the sigdie() in sshd.c and implements the LoginGraceTime logging in the listener process. E.g. Timeout before authentication for connection from [10.40.0.253]: to [172.30.30.4]:51846 (pid = 28473) It also implements infrastructure for logging abnormal terminations (e.g. the monitor exiting with SIGSEGV) and adds a framework for custom handling of arbitrary monitor exit statuses that we can reuse to remove the auth-pam.c sigdie() calls. Oh, and it adds a SIGINFO handler to the listener for debugging :) Also at https://github.com/djmdjm/openssh-wip/pull/22 -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3598] Dead lock of sshd and Defunct of sshd
https://bugzilla.mindrot.org/show_bug.cgi?id=3598 --- Comment #6 from Darren Tucker --- (In reply to Damien Miller from comment #5) > Other options > include implementing LoginGraceTime in the monitor mainloop That's non-trivial since some of the potential timeouts are prior to the monitor mainloop eg kex_exchange_identification(). > or having the listener do the logging (AFAIK it's still around at this > point for MaxStartups tracking) That should be doable with a bit of plumbing, the only caveat I can think of is that the timeout log messages will come from a pid not directly associated with the connection. -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3598] Dead lock of sshd and Defunct of sshd
https://bugzilla.mindrot.org/show_bug.cgi?id=3598
--- Comment #5 from Damien Miller ---
nerfing sigdie would mean that we lose the following log messages:
auth-pam.c: sigdie("PAM: authentication thread exited
unexpectedly");
auth-pam.c: sigdie("PAM: authentication thread exited
uncleanly");
sshd.c: sigdie("Timeout before authentication for %s port %d",
I was about to suggest what Darren said re arranging for the process to
exit with a magic value and moving the logging to the parent, but I see
that he beat me to it :)
OTOH I don't love the idea of moving the grace alarm to the privsep
child, since it's intended not to be trustworthy. Other options include
implementing LoginGraceTime in the monitor mainloop or having the
listener do the logging (AFAIK it's still around at this point for
MaxStartups tracking)
--
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3598] Dead lock of sshd and Defunct of sshd
https://bugzilla.mindrot.org/show_bug.cgi?id=3598 --- Comment #4 from Darren Tucker --- (In reply to Damien Miller from comment #3) > IMO the problem is fundamentally that we're doing operations in a > signal handler that are unsafe on some platforms. That's true but I don't think it's the problem here, unless they just happen to be hitting a signal race at exactly 90s. > We should probably > make sigdie() a noop anywhere snprintf()+syslog() are not guaranteed > to be safe, which AFAIK is everything other than OpenBSD. Now that privsep is mandatory we could move the LoginGraceTime signal handler into the privsep child and just have it _exit(somenumber), then have the monitor read that exit code in its normal event loop and log from there. I have most of the code for the monitor side written as part of another thing. -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3598] Dead lock of sshd and Defunct of sshd
https://bugzilla.mindrot.org/show_bug.cgi?id=3598 Damien Miller changed: What|Removed |Added CC||d...@mindrot.org --- Comment #3 from Damien Miller --- IMO the problem is fundamentally that we're doing operations in a signal handler that are unsafe on some platforms. We should probably make sigdie() a noop anywhere snprintf()+syslog() are not guaranteed to be safe, which AFAIK is everything other than OpenBSD. -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3598] Dead lock of sshd and Defunct of sshd
https://bugzilla.mindrot.org/show_bug.cgi?id=3598 --- Comment #2 from mzhan017 --- Darren, Yes, you're correct. We could be blocked in the first syslog call, even without the dead lock. But still could face the issue of the number of process/memory usage kept increasing. Is it possible to defense such situation of blocked syslog? That may could make sure that we could still login the system stable by ssh. Thanks, Mark -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3598] Dead lock of sshd and Defunct of sshd
https://bugzilla.mindrot.org/show_bug.cgi?id=3598 Darren Tucker changed: What|Removed |Added CC||dtuc...@dtucker.net --- Comment #1 from Darren Tucker --- Created attachment 3710 --> https://bugzilla.mindrot.org/attachment.cgi?id=3710&action=edit Block signals while sysloggin You could try blocking signals while it's in syslog. That said, if the problem is that it's blocking in syslog indefinitely in the first call (and if it's timing out after 90s, that seems likely) you'll still have sshds blocked in syslog. -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
