Displaying 5 results from an estimated 5 matches for "philcerf".
2014 Nov 22
6
[Bug 2320] New: end-of-line comments work in sshd_config but not in ssh_config
...ssh_config
Product: Portable OpenSSH
Version: 6.7p1
Hardware: Other
OS: Linux
Status: NEW
Severity: normal
Priority: P5
Component: ssh
Assignee: unassigned-bugs at mindrot.org
Reporter: philcerf at gmail.com
Dear OpenSSH developers.
I just found out that end-of-line comments, e.g.
AllowUser foo #bar baz
seem to work in sshd_config, but they don't in ssh_config.
Having them in the later gives some error like:
$ ssh host
/etc/ssh/ssh_config line 23: garbage at end of line; "#bar...
2014 Dec 01
4
[Bug 2322] New: please let the server enable/disable delayed compression on a per user basis
...er user basis
Product: Portable OpenSSH
Version: 3.7p1
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P5
Component: sshd
Assignee: unassigned-bugs at mindrot.org
Reporter: philcerf at gmail.com
Hi.
This is basically from
https://lists.mindrot.org/pipermail/openssh-unix-dev/2014-November/033176.html
.
1) In encryption, compression may generally be abused as an oracle for
side-channel attack, when the attacker can inject chosen-plaintext
(e.g. as in CRIME and BREACH attacks...
2014 Nov 18
5
can compression be safely used with SSH?
Hello.
At work we collect logs (via ssh) from all kinds of hosts on one
central node which has no connection to the internet and is tried to
kept secure.
The idea is, as you can imagine, that in case of a compromise we'd
have at least all the logs up to the break without any forgeries.
The logging is done continuously and compression is used.
Now the following is not really that much
2022 Dec 29
1
per-connection sshd doesn't always pass on SIGQUIT
Hey.
On Thu, Dec 29, 2022 at 1:28 AM Damien Miller <djm at mindrot.org> wrote:
> It's because the monitor process doesn't explicitly handle SIGQUIT.
Are you going to merge the patch of yours?
Best wishes,
Philippe.
2022 Dec 27
2
per-connection sshd doesn't always pass on SIGQUIT
Hey.
I've noticed the following behavior and wondered whether it's possibly
a bug or why it behaves like this:
When having a SSH connection, than it seems there may be two sshd
processes for that, one running as root the other as the user. As far
as I know this is because of privilege separation, like e.g.:
??sshd(2931)???sshd(10174)???bash(10180)
?