search for: _accept

...nce). As far as we are aware, there is no way for an attacker to realign the keystream to allow the session to continue. Note however, that the attack still passes MAC verification and that an exception is only thrown at the application layer (i.e. wrong message format of SSH_SERVICE_REQUEST / _ACCEPT). > So is keeping hmac-etm iff aes-ctr is offered used still a safe option (or just "not broken"). Because luckily many > have removed CBC already. From our current point of view, this combination can be used without risking any real world attack. However, this may change if some...

...hrough libc.so and then through libucb.a. Don't let ld search in /usr/ucblib, it will virtually always produce nonsense. - often found mistake with libsocket and libnsl: Especially libsocket MUST be bound before libc. Otherwise you will get lots of messages like unix: syslog: 7784 sshd:_accept: SIOCGPGRP failed errno 22 - -ldl not choosen by configure: Something in OpenSSH (I did not find) needs libdl. configure checks for dlopen() only when it finds PAM. No PAM on ReliantUNIX, so not libdl, thus no binding. Ouch! :-) I made an XXX fix for ReliantUNIX and left it for someone else to...

Hello, in addition to my last thread about a new config option to make strict-kex mandatory, I also wonder if a new mechanism for ciphers/macs can be introduced and is reliable by simple both sides using it. So there could be a Chacha20-Poly1305v2 at openssh.com which uses AD data to chain the messages together, so it will be resistant against terrapin even without the strict-kex. Consequently