I've had the following three unresolved problems (apart from the workaround I point out for #3) since my upgrade to OpenBSD 5.0, all involving ssh and/or ssl:
1. I use TLS with postfix, with certificates on all machines. My colo-hosted mail server sending mail via IPv6 to an internal host intermittently has TLS handshake failures on the sending side and corresponding SSLv3 certificate read failures on the receiving side, e.g.: postfix/smtpd[6407]: SSL_accept:SSLv3 flush data postfix/smtpd[6407]: read from 856B5840 [88646003] (5 bytes => -1 (0xFFFFFFFF)) postfix/smtpd[22219]: read from 8ACC5080 [83CC9003] (5 bytes => 0 (0x0)) postfix/smtpd[22219]: SSL_accept:failed in SSLv3 read client certificate A and, on the sending side: postfix/smtp[3289]: 05817984EB: Cannot start TLS: handshake failure While I had this problem consistently (i.e., it failed every time) in OpenBSD 4.9, I was able to fix it by patching libssl/src/ssl/t1_lib.c with the EC point format list fix from OpenSSL 1.0.0c. Applying that patch to OpenSSL 5.0 doesn't fix the problem, which is intermittent (but extremely frequent) rather than consistent. 2. When using scp to copy files from my internal network to my colo box, it works without problem via IPv4, but comes to a halt as the transfer reaches 100% via IPv6, leaving a zero-length file on the receiving end. For example: debug1: Sending command: scp -v -t -- ./ debug2: channel 0: request exec confirm 1 debug2: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel 0: rcvd adjust 2097152 debug2: channel_input_status_confirm: type 99 id 0 debug2: exec request accepted on channel 0 Sending file modes: C0664 50358 t1_lib.c debug2: channel 0: rcvd ext data 27 t1_lib.c 0% 0 0.0KB/s --:-- ETASink: C0664 50358 t1_lib.c debug2: channel 0: written 27 to efd 6 t1_lib.c 100% 49KB 49.2KB/s 00:00 And then the connection is dropped after a timeout. 3. SSH via IPv6 to my colo box from my internal network fails due to a problem with the length of the host key algorithms list; the workaround is to use an abbreviated list like this in my .ssh/config file for that host: HostKeyAlgorithms ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss This problem is discussed here: http://www.gossamer-threads.com/lists/openssh/dev/51411?do=post_view_threaded#51411 This ssh -vv output shows where it stops: [...] debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac...@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac...@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,z...@openssh.com debug2: kex_parse_kexinit: none,z...@openssh.com debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: found hmac-md5 debug1: kex: server->client aes128-ctr hmac-md5 none debug2: mac_setup: found hmac-md5 debug1: kex: client->server aes128-ctr hmac-md5 none debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY -- Jim Lippard lippard-open...@discord.org http://www.discord.org/ GPG Key ID: 0xF8D42CFE