Re: Strange kernel panic-like problem
On Thu, Feb 07, 2019 at 11:18:40PM -0600, Kyle wrote:
> I recently upgraded a box running 6.2 to 6.4 via clean install. After a few
> days of running normally it started locking up, usually within a minute or so
> after booting up to the login prompt. ddb appears on the console.
>
> I eventually thought to try booting bsd.sp, which has been running for about
> a day now without locking up.
>
> Any clues to point me in the right direction would be much appreciated.
>
> Here's some excerpts from the serial console (different sessions) and a dmesg:
>
>
> ddb{0}> show panic
> the kernel did not panic
> ddb{0}> trace
> acpicpu_idle() at acpicpu_idle+0x1ea
> sched_idle(0) at sched_idle+0x245
> end trace frame: 0x0, count: -2
>
>
>
> login: NMI ... going o debugger
NMIs (Non Maskable Interrupts) are often an indication of hardware problems.
-Otto
> ddb{0}䀿 movq$0x8,%rcxuaei[1;24r c
>db{}>
> ddb{0}>
> d{0}>
> ddb{0}
> ddb{0}>
> ddb{0}>
> ddb{�}>
> ddb{0>
> db{0}> show panic
> the kernel did not panic
> ddb{0}>
> the kernel did not panic
> ddb{0}>
> the kernel did not panic
> ddb{0}>
> the kernel did not panic
> ddb{0}>
> the kernel di no paniddb{0}>
> the erne i nic
> ddb{0}>
> the kernel did not nic
> ddb{0}>
> thernel id not nc
> ddb{0}>
> the keel did notpanic
> ddb{0}>
> theknel did not nic
> ddb{0}>
> the kernel did not panic
> ddb{0}>
> the kernel did not panic
> ddb{0}>
> the kernel did not panc
> ddb0}>
> the kernel did not panic
> ddb{0}> traccce
> No such command
> ddb{0}>
> the kernel did not panic
> ddb{0}> tracce
> No such command
> ddb{0}> traace
> No such command
> ddb{0}> trace
> acpicpu_idle() at acpicpu_idle+0x1ea
> sched_idle(0) at sched_idle+0x245
> end trace frame: 0x0, count: -2
> ddb{0}>
> acpicpu_idle() at acpicpu_idle+0x1ea
> end trace frame: 0x8000218fca60, count: 0
> ddb{0}>
> acpicpu_idle() at acpicpu_idle+0x1ea
> end trace frame: 0x8000218fca60, count: 0
> ddb{0}>
> acpicpu_idle() at acpicpu_idle+0x1ea
> end trace frame: 0x8000218fca60, count: 0
> ddb{0}>
> acpicpu_idle() at acpicpu_idle+0x1ea
> end trace frame: 0x8000218fca60, count: 0
> ddb{0}>
> acpicpu_idle() at acpicpu_idle+0x1ea
> end trace frame: 0x8000218fca60, count: 0
> ddb{0}>
> acpicpu_idle() at acpicpu_idle+0x1ea
> end trace frame: 0x8000218fca60, count: 0
> ddb{0}> boot dump
> syncing disks..
>
>
>
>
> ddb{1}> boot dump
> syncing disks...panic: kernel diagnostic assertion "p->p_wchan == NULL"
> failed: file "/usr/src/sys/kern/kern_sched.c", line 338
> Stopped at db_enter+0x12: popq%r11
> TIDPIDUID PRFLAGS PFLAGS CPU COMMAND
> 72309 19595 730x100010 0x800 syslogd
> db_enter() at db_enter+0x12
> panic() at panic+0x120
> __assert(811929f4,80002191fa00,800021750ff0,8000e960)
> a
> t __assert+0x24
> sched_chooseproc() at sched_chooseproc+0x241
> mi_switch() at mi_switch+0x1b4
> sleep_finish(6d3fbc03daad5a02,80002191fb10) at sleep_finish+0x7f
> sleep_finish_all(270c6ff115c03531,80002191fb10) at sleep_finish_all+0x1f
> tsleep(64263b673ec8ed92,ff02417d4200,ff027f616830,65420) at
> tsleep+0xcd
>
> getblk(f6e14443bcd449df,ff027f6167d0,80002191fd00,0,ff027f3d3000)
> a
> t getblk+0xf5
> bread(80145000,ff027f616a28,ff027f3d3000,0) at bread+0x1b
> ffs_update(292bb10918b461bf,ff027f616a28) at ffs_update+0xfc
> VOP_FSYNC(f6e14443bcb92266,80002191fe38,2be1d547d68afbf,8000e960)
> a
> t VOP_FSYNC+0x52
> ffs_sync_vnode(5116a32c89f5a557,80002191fe38) at ffs_sync_vnode+0xd2
> vfs_mount_foreach_vnode(9582de35d54b8f61,2,8000e960) at
> vfs_mount_forea
> ch_vnode+0x4e
> end trace frame: 0x80002191fea0, count: 0
> https://www.openbsd.org/ddb.html describes the minimum info required in bug
> reports. Insufficient info makes it difficult to find and fix bugs.
> ddb{1}> boot sync
> panic: kernel diagnostic assertion "__mp_lock_held(&sched_lock, curcpu()) ==
> 0" failed: file "/usr/src/sys/kern/kern_lock.c", line 63
> Stopped at db_enter+0x12: popq%r11
> db_enter() at db_enter+0x12
> panic() at panic+0x120
> __assert(811929f4,80002191f530,0,ff02369aeae8) at
> __assert+0x24
>
> _kernel_lock(778d687e7309b96e,1) at _kernel_lock+0xea
> solock(537a4000962b3bf3) at solock+0x44
> route_input(6e54ffebe841494b,80002191f610,8012f000) at
> route_input+
> 0xd1
> if_down(8012f000) at if_down+0x94
> if_downall() at if_downall+0x62
> boot(c) at boot+0x8d
> reboot(4800) at reboot+0x5a
> nvramattach(81d05260) at nvramattach
> db_boot_sync_cmd(819a1c9e,80002191f6c0,81d05260,1) at
> db_bo
> ot_sync_cmd+0xe
> db_command(be4ef64b60647db8,0) at db_command+0x2b4
> db_command_loop() at db_command_loop+0x96
> end trace frame: 0x80002191f820, count: 0
> ddb{1}>
>
>
>
> ddb{1}> dmesg
> OpenBSD 6.4 (GENERIC.MP) #6: Sat Jan 26 20:37
Strange kernel panic-like problem
I recently upgraded a box running 6.2 to 6.4 via clean install. After a few
days of running normally it started locking up, usually within a minute or so
after booting up to the login prompt. ddb appears on the console.
I eventually thought to try booting bsd.sp, which has been running for about a
day now without locking up.
Any clues to point me in the right direction would be much appreciated.
Here's some excerpts from the serial console (different sessions) and a dmesg:
ddb{0}> show panic
the kernel did not panic
ddb{0}> trace
acpicpu_idle() at acpicpu_idle+0x1ea
sched_idle(0) at sched_idle+0x245
end trace frame: 0x0, count: -2
login: NMI ... going o debugger
ddb{0}䀿 movq$0x8,%rcxuaei[1;24r c
db{}>
ddb{0}>
d{0}>
ddb{0}
ddb{0}>
ddb{0}>
ddb{�}>
ddb{0>
db{0}> show panic
the kernel did not panic
ddb{0}>
the kernel did not panic
ddb{0}>
the kernel did not panic
ddb{0}>
the kernel did not panic
ddb{0}>
the kernel di no paniddb{0}>
the erne i nic
ddb{0}>
the kernel did not nic
ddb{0}>
thernel id not nc
ddb{0}>
the keel did notpanic
ddb{0}>
theknel did not nic
ddb{0}>
the kernel did not panic
ddb{0}>
the kernel did not panic
ddb{0}>
the kernel did not panc
ddb0}>
the kernel did not panic
ddb{0}> traccce
No such command
ddb{0}>
the kernel did not panic
ddb{0}> tracce
No such command
ddb{0}> traace
No such command
ddb{0}> trace
acpicpu_idle() at acpicpu_idle+0x1ea
sched_idle(0) at sched_idle+0x245
end trace frame: 0x0, count: -2
ddb{0}>
acpicpu_idle() at acpicpu_idle+0x1ea
end trace frame: 0x8000218fca60, count: 0
ddb{0}>
acpicpu_idle() at acpicpu_idle+0x1ea
end trace frame: 0x8000218fca60, count: 0
ddb{0}>
acpicpu_idle() at acpicpu_idle+0x1ea
end trace frame: 0x8000218fca60, count: 0
ddb{0}>
acpicpu_idle() at acpicpu_idle+0x1ea
end trace frame: 0x8000218fca60, count: 0
ddb{0}>
acpicpu_idle() at acpicpu_idle+0x1ea
end trace frame: 0x8000218fca60, count: 0
ddb{0}>
acpicpu_idle() at acpicpu_idle+0x1ea
end trace frame: 0x8000218fca60, count: 0
ddb{0}> boot dump
syncing disks..
ddb{1}> boot dump
syncing disks...panic: kernel diagnostic assertion "p->p_wchan == NULL" failed:
file "/usr/src/sys/kern/kern_sched.c", line 338
Stopped at db_enter+0x12: popq%r11
TIDPIDUID PRFLAGS PFLAGS CPU COMMAND
72309 19595 730x100010 0x800 syslogd
db_enter() at db_enter+0x12
panic() at panic+0x120
__assert(811929f4,80002191fa00,800021750ff0,8000e960) a
t __assert+0x24
sched_chooseproc() at sched_chooseproc+0x241
mi_switch() at mi_switch+0x1b4
sleep_finish(6d3fbc03daad5a02,80002191fb10) at sleep_finish+0x7f
sleep_finish_all(270c6ff115c03531,80002191fb10) at sleep_finish_all+0x1f
tsleep(64263b673ec8ed92,ff02417d4200,ff027f616830,65420) at tsleep+0xcd
getblk(f6e14443bcd449df,ff027f6167d0,80002191fd00,0,ff027f3d3000) a
t getblk+0xf5
bread(80145000,ff027f616a28,ff027f3d3000,0) at bread+0x1b
ffs_update(292bb10918b461bf,ff027f616a28) at ffs_update+0xfc
VOP_FSYNC(f6e14443bcb92266,80002191fe38,2be1d547d68afbf,8000e960) a
t VOP_FSYNC+0x52
ffs_sync_vnode(5116a32c89f5a557,80002191fe38) at ffs_sync_vnode+0xd2
vfs_mount_foreach_vnode(9582de35d54b8f61,2,8000e960) at vfs_mount_forea
ch_vnode+0x4e
end trace frame: 0x80002191fea0, count: 0
https://www.openbsd.org/ddb.html describes the minimum info required in bug
reports. Insufficient info makes it difficult to find and fix bugs.
ddb{1}> boot sync
panic: kernel diagnostic assertion "__mp_lock_held(&sched_lock, curcpu()) == 0"
failed: file "/usr/src/sys/kern/kern_lock.c", line 63
Stopped at db_enter+0x12: popq%r11
db_enter() at db_enter+0x12
panic() at panic+0x120
__assert(811929f4,80002191f530,0,ff02369aeae8) at __assert+0x24
_kernel_lock(778d687e7309b96e,1) at _kernel_lock+0xea
solock(537a4000962b3bf3) at solock+0x44
route_input(6e54ffebe841494b,80002191f610,8012f000) at route_input+
0xd1
if_down(8012f000) at if_down+0x94
if_downall() at if_downall+0x62
boot(c) at boot+0x8d
reboot(4800) at reboot+0x5a
nvramattach(81d05260) at nvramattach
db_boot_sync_cmd(819a1c9e,80002191f6c0,81d05260,1) at db_bo
ot_sync_cmd+0xe
db_command(be4ef64b60647db8,0) at db_command+0x2b4
db_command_loop() at db_command_loop+0x96
end trace frame: 0x80002191f820, count: 0
ddb{1}>
ddb{1}> dmesg
OpenBSD 6.4 (GENERIC.MP) #6: Sat Jan 26 20:37:44 CET 2019
r...@syspatch-64-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.
MP
real mem = 8544854016 (8149MB)
avail mem = 8276611072 (7893MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x7f4d8000 (50 entries)
bios0: vendor American Megatrends Inc. version "1.1a" date 08/27/2015
bios0: Supermicro A1SAi
acpi0 at bios0: rev 2
acpi0: sleep states S0 S5
acpi0: tables DSDT FACP FPDT FIDT SPMI MCFG WDA
Re: SSH disconnects right after accepting
Hello, Did you edit /etc/login.conf recently? -- Best Regards Maksim Rodin 08.02.2019, 03:27, "Lars Bonnesen" : > OpenBSD 6.4 > > Putty just reports "Authenticating with public key "XXX" from agent" and > then I am disconnected. If I run sshd with -ddd, I get the following > output. I can't seem to get any error, and therefor I can't tell what is > wrong. Anyone has any idea? Thanks > > debug2: load_server_config: filename /etc/ssh/sshd_config > debug2: load_server_config: done config len = 204 > debug2: parse_server_config: config /etc/ssh/sshd_config len 204 > debug3: /etc/ssh/sshd_config:25 setting LogLevel DEBUG > debug3: /etc/ssh/sshd_config:30 setting PermitRootLogin no > debug3: /etc/ssh/sshd_config:39 setting AuthorizedKeysFile > .ssh/authorized_keys > debug3: /etc/ssh/sshd_config:86 setting Subsystem sftp > /usr/libexec/sftp-server > debug1: sshd version OpenSSH_7.9, LibreSSL 2.8.2 > debug1: private host key #0: ssh-rsa SHA256:XXX > debug1: private host key #1: ecdsa-sha2-nistp256 SHA256:XXX > debug1: private host key #2: ssh-ed25519 SHA256:XXX > debug1: rexec_argv[0]='/usr/sbin/sshd' > debug1: rexec_argv[1]='-ddd' > debug2: fd 3 setting O_NONBLOCK > debug1: Bind to port 22 on 0.0.0.0. > Server listening on 0.0.0.0 port 22. > debug2: fd 4 setting O_NONBLOCK > debug1: Bind to port 22 on ::. > Server listening on :: port 22. > debug1: fd 5 clearing O_NONBLOCK > debug1: Server will not fork when running in debugging mode. > debug3: send_rexec_state: entering fd = 8 config len 204 > debug3: ssh_msg_send: type 0 > debug3: send_rexec_state: done > debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8 > debug1: inetd sockets after dupping: 3, 3 > Connection from 172.17.4.3 port 63721 on 172.17.1.2 port 22 rdomain "0" > debug1: Client protocol version 2.0; client software version > PuTTY_Release_0.70 > debug1: no match: PuTTY_Release_0.70 > debug1: Local version string SSH-2.0-OpenSSH_7.9 > debug2: fd 3 setting O_NONBLOCK > debug3: ssh_sandbox_init: preparing pledge sandbox > debug2: Network child is on pid 89382 > debug3: preauth child monitor started > debug3: privsep user:group 27:27 [preauth] > debug1: permanently_set_uid: 27/27 [preauth] > debug1: list_hostkey_types: > rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] > debug3: send packet: type 20 [preauth] > debug1: SSH2_MSG_KEXINIT sent [preauth] > debug3: receive packet: type 20 [preauth] > debug1: SSH2_MSG_KEXINIT received [preauth] > debug2: local server KEXINIT proposal [preauth] > debug2: KEX algorithms: > curve25519-sha256,curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1 > [preauth] > debug2: host key algorithms: > rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] > debug2: ciphers ctos: chacha20-poly1...@openssh.com > ,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com, > aes256-...@openssh.com [preauth] > debug2: ciphers stoc: chacha20-poly1...@openssh.com > ,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com, > aes256-...@openssh.com [preauth] > debug2: MACs ctos: umac-64-...@openssh.com,umac-128-...@openssh.com, > hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com, > hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 > [preauth] > debug2: MACs stoc: umac-64-...@openssh.com,umac-128-...@openssh.com, > hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com, > hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 > [preauth] > debug2: compression ctos: none,z...@openssh.com [preauth] > debug2: compression stoc: none,z...@openssh.com [preauth] > debug2: languages ctos: [preauth] > debug2: languages stoc: [preauth] > debug2: first_kex_follows 0 [preauth] > debug2: reserved 0 [preauth] > debug2: peer client KEXINIT proposal [preauth] > debug2: KEX algorithms: > curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,rsa2048-sha256,rsa1024-sha1,diffie-hellman-group1-sha1 > [preauth] > debug2: host key algorithms: > ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss > [preauth] > debug2: ciphers ctos: aes256-ctr,aes256-cbc,rijndael-...@lysator.liu.se > ,aes192-ctr,aes192-cbc,aes128-ctr,aes128-cbc,chacha20-poly1...@openssh.com,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arcfour256,arcfour128 > [preauth] > debug2: ciphers stoc: aes256-ctr,aes256-cbc,rijndael-...@lysator.liu.se > ,aes192-ctr,aes192-cbc,aes128-ctr,aes128-cbc,chacha20-poly1...@openssh.com,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arcfour256,arcfour128 > [preauth] > debug2: MACs ctos: hmac-sha2-256,hmac-sha1,hmac-sha1-96,hmac-md5, > hmac-sha2-256-
Re: [SUSPECTED SPAM] SSH disconnects right after accepting
On Fri, 8 Feb 2019, Lars Bonnesen wrote: > OpenBSD 6.4 > > Putty just reports "Authenticating with public key "XXX" from agent" and > then I am disconnected. If I run sshd with -ddd, I get the following > output. I can't seem to get any error, and therefor I can't tell what is > wrong. Anyone has any idea? Thanks Darren has been unable to replicate this problem using PuTTY as a client. Could you please try to see whether sshd is dumping core? You can follow the instructions at the end of "man sysctl" - search for "nosuidcoredump" to enable coredumps for the sshd process. Once that is done, you can try to reproduce your problem and then check the /var/crash/sshd directory. -d
Re: SSH disconnects right after accepting
Can you share your sshd_config file, and ~user/.ssh/rc and ~user/.ssh/config files (if they exist) please. On Fri, Feb 8, 2019 at 12:07 PM Lars Bonnesen wrote: > > No, clear text login also does not work. Only when I log on through the > console, not say. > > Regards, Lars. > > On Fri, Feb 8, 2019, 02:03 Aaron Mason > >> Hi >> >> Does it work fine if you log in with the user's password? >> >> On Fri, Feb 8, 2019 at 11:25 AM Lars Bonnesen >> wrote: >> > >> > OpenBSD 6.4 >> > >> > Putty just reports "Authenticating with public key "XXX" from agent" and >> > then I am disconnected. If I run sshd with -ddd, I get the following >> > output. I can't seem to get any error, and therefor I can't tell what is >> > wrong. Anyone has any idea? Thanks >> > >> > >> > debug2: load_server_config: filename /etc/ssh/sshd_config >> > debug2: load_server_config: done config len = 204 >> > debug2: parse_server_config: config /etc/ssh/sshd_config len 204 >> > debug3: /etc/ssh/sshd_config:25 setting LogLevel DEBUG >> > debug3: /etc/ssh/sshd_config:30 setting PermitRootLogin no >> > debug3: /etc/ssh/sshd_config:39 setting AuthorizedKeysFile >> > .ssh/authorized_keys >> > debug3: /etc/ssh/sshd_config:86 setting Subsystem sftp >> > /usr/libexec/sftp-server >> > debug1: sshd version OpenSSH_7.9, LibreSSL 2.8.2 >> > debug1: private host key #0: ssh-rsa SHA256:XXX >> > debug1: private host key #1: ecdsa-sha2-nistp256 SHA256:XXX >> > debug1: private host key #2: ssh-ed25519 SHA256:XXX >> > debug1: rexec_argv[0]='/usr/sbin/sshd' >> > debug1: rexec_argv[1]='-ddd' >> > debug2: fd 3 setting O_NONBLOCK >> > debug1: Bind to port 22 on 0.0.0.0. >> > Server listening on 0.0.0.0 port 22. >> > debug2: fd 4 setting O_NONBLOCK >> > debug1: Bind to port 22 on ::. >> > Server listening on :: port 22. >> > debug1: fd 5 clearing O_NONBLOCK >> > debug1: Server will not fork when running in debugging mode. >> > debug3: send_rexec_state: entering fd = 8 config len 204 >> > debug3: ssh_msg_send: type 0 >> > debug3: send_rexec_state: done >> > debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8 >> > debug1: inetd sockets after dupping: 3, 3 >> > Connection from 172.17.4.3 port 63721 on 172.17.1.2 port 22 rdomain "0" >> > debug1: Client protocol version 2.0; client software version >> > PuTTY_Release_0.70 >> > debug1: no match: PuTTY_Release_0.70 >> > debug1: Local version string SSH-2.0-OpenSSH_7.9 >> > debug2: fd 3 setting O_NONBLOCK >> > debug3: ssh_sandbox_init: preparing pledge sandbox >> > debug2: Network child is on pid 89382 >> > debug3: preauth child monitor started >> > debug3: privsep user:group 27:27 [preauth] >> > debug1: permanently_set_uid: 27/27 [preauth] >> > debug1: list_hostkey_types: >> > rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] >> > debug3: send packet: type 20 [preauth] >> > debug1: SSH2_MSG_KEXINIT sent [preauth] >> > debug3: receive packet: type 20 [preauth] >> > debug1: SSH2_MSG_KEXINIT received [preauth] >> > debug2: local server KEXINIT proposal [preauth] >> > debug2: KEX algorithms: >> > curve25519-sha256,curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1 >> > [preauth] >> > debug2: host key algorithms: >> > rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] >> > debug2: ciphers ctos: chacha20-poly1...@openssh.com >> > ,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com, >> > aes256-...@openssh.com [preauth] >> > debug2: ciphers stoc: chacha20-poly1...@openssh.com >> > ,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com, >> > aes256-...@openssh.com [preauth] >> > debug2: MACs ctos: umac-64-...@openssh.com,umac-128-...@openssh.com, >> > hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com, >> > hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 >> > [preauth] >> > debug2: MACs stoc: umac-64-...@openssh.com,umac-128-...@openssh.com, >> > hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com, >> > hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 >> > [preauth] >> > debug2: compression ctos: none,z...@openssh.com [preauth] >> > debug2: compression stoc: none,z...@openssh.com [preauth] >> > debug2: languages ctos: [preauth] >> > debug2: languages stoc: [preauth] >> > debug2: first_kex_follows 0 [preauth] >> > debug2: reserved 0 [preauth] >> > debug2: peer client KEXINIT proposal [preauth] >> > debug2: KEX algorithms: >> > curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,rsa2048-sha256,rsa1024-sha1,diffie-hellman-group1-sha1 >> > [preauth] >> > debug2: host key algorithms: >> > ssh-ed25519,ecdsa-sha2-nistp256,ec
Re: SSH disconnects right after accepting
Hi Does it work fine if you log in with the user's password? On Fri, Feb 8, 2019 at 11:25 AM Lars Bonnesen wrote: > > OpenBSD 6.4 > > Putty just reports "Authenticating with public key "XXX" from agent" and > then I am disconnected. If I run sshd with -ddd, I get the following > output. I can't seem to get any error, and therefor I can't tell what is > wrong. Anyone has any idea? Thanks > > > debug2: load_server_config: filename /etc/ssh/sshd_config > debug2: load_server_config: done config len = 204 > debug2: parse_server_config: config /etc/ssh/sshd_config len 204 > debug3: /etc/ssh/sshd_config:25 setting LogLevel DEBUG > debug3: /etc/ssh/sshd_config:30 setting PermitRootLogin no > debug3: /etc/ssh/sshd_config:39 setting AuthorizedKeysFile > .ssh/authorized_keys > debug3: /etc/ssh/sshd_config:86 setting Subsystem sftp > /usr/libexec/sftp-server > debug1: sshd version OpenSSH_7.9, LibreSSL 2.8.2 > debug1: private host key #0: ssh-rsa SHA256:XXX > debug1: private host key #1: ecdsa-sha2-nistp256 SHA256:XXX > debug1: private host key #2: ssh-ed25519 SHA256:XXX > debug1: rexec_argv[0]='/usr/sbin/sshd' > debug1: rexec_argv[1]='-ddd' > debug2: fd 3 setting O_NONBLOCK > debug1: Bind to port 22 on 0.0.0.0. > Server listening on 0.0.0.0 port 22. > debug2: fd 4 setting O_NONBLOCK > debug1: Bind to port 22 on ::. > Server listening on :: port 22. > debug1: fd 5 clearing O_NONBLOCK > debug1: Server will not fork when running in debugging mode. > debug3: send_rexec_state: entering fd = 8 config len 204 > debug3: ssh_msg_send: type 0 > debug3: send_rexec_state: done > debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8 > debug1: inetd sockets after dupping: 3, 3 > Connection from 172.17.4.3 port 63721 on 172.17.1.2 port 22 rdomain "0" > debug1: Client protocol version 2.0; client software version > PuTTY_Release_0.70 > debug1: no match: PuTTY_Release_0.70 > debug1: Local version string SSH-2.0-OpenSSH_7.9 > debug2: fd 3 setting O_NONBLOCK > debug3: ssh_sandbox_init: preparing pledge sandbox > debug2: Network child is on pid 89382 > debug3: preauth child monitor started > debug3: privsep user:group 27:27 [preauth] > debug1: permanently_set_uid: 27/27 [preauth] > debug1: list_hostkey_types: > rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] > debug3: send packet: type 20 [preauth] > debug1: SSH2_MSG_KEXINIT sent [preauth] > debug3: receive packet: type 20 [preauth] > debug1: SSH2_MSG_KEXINIT received [preauth] > debug2: local server KEXINIT proposal [preauth] > debug2: KEX algorithms: > curve25519-sha256,curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1 > [preauth] > debug2: host key algorithms: > rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] > debug2: ciphers ctos: chacha20-poly1...@openssh.com > ,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com, > aes256-...@openssh.com [preauth] > debug2: ciphers stoc: chacha20-poly1...@openssh.com > ,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com, > aes256-...@openssh.com [preauth] > debug2: MACs ctos: umac-64-...@openssh.com,umac-128-...@openssh.com, > hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com, > hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 > [preauth] > debug2: MACs stoc: umac-64-...@openssh.com,umac-128-...@openssh.com, > hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com, > hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 > [preauth] > debug2: compression ctos: none,z...@openssh.com [preauth] > debug2: compression stoc: none,z...@openssh.com [preauth] > debug2: languages ctos: [preauth] > debug2: languages stoc: [preauth] > debug2: first_kex_follows 0 [preauth] > debug2: reserved 0 [preauth] > debug2: peer client KEXINIT proposal [preauth] > debug2: KEX algorithms: > curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,rsa2048-sha256,rsa1024-sha1,diffie-hellman-group1-sha1 > [preauth] > debug2: host key algorithms: > ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss > [preauth] > debug2: ciphers ctos: aes256-ctr,aes256-cbc,rijndael-...@lysator.liu.se > ,aes192-ctr,aes192-cbc,aes128-ctr,aes128-cbc,chacha20-poly1...@openssh.com,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arcfour256,arcfour128 > [preauth] > debug2: ciphers stoc: aes256-ctr,aes256-cbc,rijndael-...@lysator.liu.se > ,aes192-ctr,aes192-cbc,aes128-ctr,aes128-cbc,chacha20-poly1...@openssh.com,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arcfour256,arcfour128 > [preauth] > debug2: MACs ctos: hmac-sha2-256,hmac-sha1,hmac-sha1-96,hmac-md5, > hmac-
SSH disconnects right after accepting
OpenBSD 6.4 Putty just reports "Authenticating with public key "XXX" from agent" and then I am disconnected. If I run sshd with -ddd, I get the following output. I can't seem to get any error, and therefor I can't tell what is wrong. Anyone has any idea? Thanks debug2: load_server_config: filename /etc/ssh/sshd_config debug2: load_server_config: done config len = 204 debug2: parse_server_config: config /etc/ssh/sshd_config len 204 debug3: /etc/ssh/sshd_config:25 setting LogLevel DEBUG debug3: /etc/ssh/sshd_config:30 setting PermitRootLogin no debug3: /etc/ssh/sshd_config:39 setting AuthorizedKeysFile .ssh/authorized_keys debug3: /etc/ssh/sshd_config:86 setting Subsystem sftp /usr/libexec/sftp-server debug1: sshd version OpenSSH_7.9, LibreSSL 2.8.2 debug1: private host key #0: ssh-rsa SHA256:XXX debug1: private host key #1: ecdsa-sha2-nistp256 SHA256:XXX debug1: private host key #2: ssh-ed25519 SHA256:XXX debug1: rexec_argv[0]='/usr/sbin/sshd' debug1: rexec_argv[1]='-ddd' debug2: fd 3 setting O_NONBLOCK debug1: Bind to port 22 on 0.0.0.0. Server listening on 0.0.0.0 port 22. debug2: fd 4 setting O_NONBLOCK debug1: Bind to port 22 on ::. Server listening on :: port 22. debug1: fd 5 clearing O_NONBLOCK debug1: Server will not fork when running in debugging mode. debug3: send_rexec_state: entering fd = 8 config len 204 debug3: ssh_msg_send: type 0 debug3: send_rexec_state: done debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8 debug1: inetd sockets after dupping: 3, 3 Connection from 172.17.4.3 port 63721 on 172.17.1.2 port 22 rdomain "0" debug1: Client protocol version 2.0; client software version PuTTY_Release_0.70 debug1: no match: PuTTY_Release_0.70 debug1: Local version string SSH-2.0-OpenSSH_7.9 debug2: fd 3 setting O_NONBLOCK debug3: ssh_sandbox_init: preparing pledge sandbox debug2: Network child is on pid 89382 debug3: preauth child monitor started debug3: privsep user:group 27:27 [preauth] debug1: permanently_set_uid: 27/27 [preauth] debug1: list_hostkey_types: rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] debug3: send packet: type 20 [preauth] debug1: SSH2_MSG_KEXINIT sent [preauth] debug3: receive packet: type 20 [preauth] debug1: SSH2_MSG_KEXINIT received [preauth] debug2: local server KEXINIT proposal [preauth] debug2: KEX algorithms: curve25519-sha256,curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1 [preauth] debug2: host key algorithms: rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] debug2: ciphers ctos: chacha20-poly1...@openssh.com ,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com, aes256-...@openssh.com [preauth] debug2: ciphers stoc: chacha20-poly1...@openssh.com ,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com, aes256-...@openssh.com [preauth] debug2: MACs ctos: umac-64-...@openssh.com,umac-128-...@openssh.com, hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com, hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 [preauth] debug2: MACs stoc: umac-64-...@openssh.com,umac-128-...@openssh.com, hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com, hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 [preauth] debug2: compression ctos: none,z...@openssh.com [preauth] debug2: compression stoc: none,z...@openssh.com [preauth] debug2: languages ctos: [preauth] debug2: languages stoc: [preauth] debug2: first_kex_follows 0 [preauth] debug2: reserved 0 [preauth] debug2: peer client KEXINIT proposal [preauth] debug2: KEX algorithms: curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,rsa2048-sha256,rsa1024-sha1,diffie-hellman-group1-sha1 [preauth] debug2: host key algorithms: ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss [preauth] debug2: ciphers ctos: aes256-ctr,aes256-cbc,rijndael-...@lysator.liu.se ,aes192-ctr,aes192-cbc,aes128-ctr,aes128-cbc,chacha20-poly1...@openssh.com,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arcfour256,arcfour128 [preauth] debug2: ciphers stoc: aes256-ctr,aes256-cbc,rijndael-...@lysator.liu.se ,aes192-ctr,aes192-cbc,aes128-ctr,aes128-cbc,chacha20-poly1...@openssh.com,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arcfour256,arcfour128 [preauth] debug2: MACs ctos: hmac-sha2-256,hmac-sha1,hmac-sha1-96,hmac-md5, hmac-sha2-256-...@openssh.com,hmac-sha1-...@openssh.com, hmac-sha1-96-...@openssh.com,hmac-md5-...@openssh.com [preauth] debug2: MACs stoc: hmac-sha2-256,hmac-sha1,hmac-sha1-96,hmac-md5, hmac-sha2-256-...@openssh.com,hmac-sha1-...@openssh.com, hmac-sha1-96-...@openssh.com,hmac-md5-...@openssh.com [preauth] d
Re: OpenBSD 6.4 cu and cuaU0
As an irony, your email footer note is a perfect answer for your questions. How did you try to kill it? Send more info, please.
Re: Relayd with multiple lets encrypt cert's
Hi Stuart, > Sent: Monday, December 24, 2018 at 1:13 AM > From: "Stuart Henderson" > To: misc@openbsd.org > Subject: Re: Relayd with multiple lets encrypt cert's > > On 2018-12-22, Aham Brahmasmi wrote: > >> On Sat, Dec 22, 2018 at 12:28:46PM +0100, Aham Brahmasmi wrote: > >> > Hi, > >> > > >> > > On Sat, Dec 22, 2018 at 07:07:58AM +0100, Flipchan wrote: > >> > > > Hello, > >> > > > Does anyone know how to get this working with multiple letsencrypt > >> > > > certs? > >> > > > > >> > > > >> > > You need individual IP:port settings for each of the certs. Also don't > >> > > forward to different hosts based on match rules unless you really know > >> > > what you are doing. The backend system is only evaluated at the start > >> > > of > >> > > the connection and so keepalive sessions will not route correctly. > >> > > > >> > > -- > >> > > :wq Claudio > >> > > >> > Would having a single SAN certificate help in this case [1]? > >> > > >> > >> Yes and no. It would make listening on one port possible but it does not > >> solve the issue of 'match forward to' being sticky for a connection. > >> > >> -- > >> :wq Claudio > > > > Danke Claudio for your response. > > > > Would it be possible for you to please elaborate on the 'match forward > > to' being sticky for a connection? I presume that there is some problem > > which might occur due to this. > > A request comes in with some Host geader, relayd decides the destination > based on this and proxies the request. Client does keepalive and > holds on to the connection for use with another request to the same > destination IP. Client then sends a second request - different Host: > header on the same IP. relayd already picked a backend with the first > request and sends it there rather than doing a fresh lookup based on the > second Host header. I am sorry for the delay in my response. Thank you for the simple and helpful explanation. I had not thought about this possibility of the client reusing the underlying connection to an IP:port shared by different hosts. Dhanyavaad. Regards, ab -|-|-|-|-|-|-|--
Re: How to print nicely formatted man pages?
Hi, Sijmen J. Mulder wrote on Thu, Feb 07, 2019 at 05:41:57PM +0100: > Op do feb 7 2019, om 14:33 schreef Ingo Schwarze: >> But please, if you can, always provide complete, working, tested >> command invocations to users, in this case: > Apologies - I was on mobile which but that's no excuse. No need to apologize - a timely and correct answer is of course better than no answer. I didn't intend to discourage that. :) Yours, Ingo
Re: How to print nicely formatted man pages?
Op do feb 7 2019, om 14:33 schreef Ingo Schwarze: > But please, if you can, always provide complete, working, tested > command invocations to users, in this case: Apologies - I was on mobile which but that's no excuse.
Re: How to print nicely formatted man pages?
Hi Anne, Anne Wainwright wrote on Thu, Feb 07, 2019 at 05:54:04PM +0200: > I have now got well-formatted pages chugging out from the printer. Good. :-) > I did use the example at the end of the mandoc man which outputs .ps > files. But I did not succeed in persuading lp to print them. Thus: > > $ lp lpadmin.ps > lp: no file in print request > > so not sure what the issue is there, but what I have is what I need. A command called "lp" simply doesn't exist in the OpenBSD base system: $ man lp man: No entry for lp in the manual. $ which lp which: lp: Command not found. Just use lpr(1) = /usr/bin/lpr. $ pkglocate bin/lp | grep 'lp$' cups-2.2.10p0:print/cups,-main:/usr/local/bin/lp I'd advise against using cups when you can avoid it. It is a behemoth that is extremely poorly designed, and the documentation of cups is of terrible quality. You are no doubt in for no end of surprises if you attempt to use cups. Admittedly, with some low-quality printers, using it may look like an easy workaround for other problems. But if your printer understands PostScript, you should be just fine without cups. Yours, Ingo
Re: How to print nicely formatted man pages?
Hi Peter, Peter N. M. Hansteen wrote on Thu, Feb 07, 2019 at 10:26:03AM +0100: > On Thu, Feb 07, 2019 at 09:29:39AM +0200, Anne Wainwright wrote: >> I can print out nicely formatted man pages in linux, thus: >> >> $ man -t ls | lpr -P hp_laserjet >> >> But find that the -t option is not present in bsd. >> >> Have really dug around but can find no hints, where should I be looking? > I would say what you are probably looking for is mandoc (man mandoc or > http://man.openbsd.org/mandoc), which supports a variety of output formats. That answer is mostly correct in so far as the mandoc(1) manual page indeed documents the -T option and PostScript output mode, but it is also slightly misleading for the following reason: If there is anything you can do with apropos(1), whatis(1), or mandoc(1), then you can do exactly the same thing with man(1): apropos ... == man -k ... whatis ... == man -f ... mandoc ... == man -lc ... where "..." stands for additional options and arguments. So "mandoc" no longer has significance as a separate program with distinct options and/or functionality: it is just the same program as man(1), except for having -l and -c active by default. Of course the name "mandoc" is still significant for the (portable) software package implementing man(1), apropos(1), whatis(1), help(1), mandoc(1), makewhatis(8), and man.cgi(8) in OpenBSD style. Yours, Ingo
Re: How to print nicely formatted man pages?
Hi, Sijmen J. Mulder wrote on Thu, Feb 07, 2019 at 09:50:47AM +0100: > Op 7 feb. 2019 om 08:29 heeft Anne Wainwright het volgende geschreven: >> I can print out nicely formatted man pages in linux, thus: >> >> $ man -t ls | lpr -P hp_laserjet >> >> But find that the -t option is not present in bsd. >> >> Have really dug around but can find no hints, where should I be looking? > man supports mandoc's -T option, e.g.: > > man -T ps | ... That is the correct answer. But please, if you can, always provide complete, working, tested command invocations to users, in this case: $ man -T ps ls > ls.ps to generate a PostScript file on disk or $ man -T ps ls | lpr to directly send the same PostScript code to the default printer. That practice helps to avoid misunderstandings and to promote good idioms. > There's a little note about it at the end of the option list in > man's man page. See mandoc's man page for the formats and such. Exactly. The reason for doing it like that was to keep the man(1) manual page simple because new users have to read that quite early when they are not yet experienced. It would be of dubious benefit to put lots of rarely-used non-standard options into the man(1) manual. Besides, duplicate information is also a problem - both for maintenance and because it forces readers to scan and compare two (identical? similar? or subtly different?) versions. As to why we have mo -t option, see http://mandoc.bsd.lv/man/man.options.1.html http://mandoc.bsd.lv/man/man.options.1.html#t Even though it is similar to -T ps in most man(1) implementations, it has ambiguous meanings in the wider program family, in particular: - preprocess with tbl(7) in groff - test = check manual pages in the hierarchy with mandb - test = check files for problems related to mandoc.db(5) in makewhatis So i decided it is best to not implement an alias -t, also because every alias makes the documentation longer, and it is best to get used to the -T ps option which needs to be supported anyway. Yours, Ingo
Re: SPA112 VoIP with pf and NAT - States keeps open on address change
On 2019-02-06, Patrick wrote: > My nat rule use the parenthesis and all other devices behind the > firewall works fine. I think it’s more a specific issue with the SPA112. > I have also set the ruleset optimization to conservative but in this > case the generated state has just a longer time to live. This isn’t the > problem because the SPA112 sends regular keep alive packets which reset > the counter for the state. Setting to 'conservative' (i.e. hanging on to states for longer) can't help with this. Using parentheses won't help either, that means "do a lookup at state creation time", but you aren't getting a new state created because the old one hasn't expired. > > Here the related rules: > pass out quick on egress inet from (vether0:network) nat-to (egress) modulate > state > pass in on egress inet proto udp from to (egress) port 5060 > > As I’m just reading again my rules. Is the modulate state the problem? > Or will pf use keep state for UDP packets as the default? PF uses "keep state" by default, and "keep state" is required for NAT. I think your main options are: - use a *shorter* timeout for this rule (this can be set per-rule and overrides the default from "set optimization") and have a port forward rule so that incoming packets still work even when the state has timed out - arrange a way to flush these states when the IP changes The first of these is probably easiest if you can do it ..
Re: How to print nicely formatted man pages?
On Thu, Feb 07, 2019 at 09:29:39AM +0200, Anne Wainwright wrote: > I can print out nicely formatted man pages in linux, thus: > > $ man -t ls | lpr -P hp_laserjet > > But find that the -t option is not present in bsd. > > Have really dug around but can find no hints, where should I be looking? I would say what you are probably looking for is mandoc (man mandoc or http://man.openbsd.org/mandoc), which supports a variety of output formats. - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: How to print nicely formatted man pages?
> Op 7 feb. 2019 om 08:29 heeft Anne Wainwright het > volgende geschreven: > > I can print out nicely formatted man pages in linux, thus: > > $ man -t ls | lpr -P hp_laserjet > > But find that the -t option is not present in bsd. > > Have really dug around but can find no hints, where should I be looking? man supports mandoc’s -T option, e.g.: man -T ps | ... There’s a little note about it at the end of the option list in man’s man page. See mandoc’s man page for the formats and such. Cheers, Sijmen
