Hi,
I posted this question to the OpenBSD bugs list last week, however
I have had no reply and it was suggested on IRC that I post here
instead. So I must apologise if this is not appropriate.
For a reference here is my previous post:
https://marc.info/?l=openbsd-bugs&m=156080681530337&w=2
I am running OpenBSD 6.5-stable (also tested on -current). When I
ssh somewhere I get a sig abort from pledge().
I use a Yubikey with GPG and use gpg-agent as my ssh-agent. I also
remote forawrd this agent. For example my .ssh/config has the following
(please note the RemoteForward is actually all on one line, I have split
it here to keep it below 80 chars):
Host www
Hostname 192.168.1.100
RemoteForward /home/tbrown/.gnupg/S.gpg-agent \
/home/tbrown/.gnupg/S.gpg-agent.extra
ExitOnForwardFailure yes
Host *
ForwardX11 no
Compression yes
ServerAliveInterval 30
ServerAliveCountMax 4
ControlMaster auto
ControlPath ~/.ssh/mux/%h_%p_%r
ControlPersist 4h
If I ssh, for example:
xps ~$ ssh www
Abort trap (core dumped)
xps ~$
I have attached output for when I crank up there verbosity (ssh_verbose.txt),
as it contains long lines.
Dmesg contains:
sh[28960]: pledge "sendfd", syscall 28
If I `ktrace` ssh, I get the following:
28960 ssh PLDG sendmsg, "sendfd", errno 1 Operation not
permitted
28960 ssh PSIG SIGABRT SIG_DFL
28960 ssh NAMI "ssh.core"
If I add sendfd to the pledge() call, it works. Please see the attached
patch (ssh.patch). However I do not know if this is an acceptable
solution.
I guess I have to ask if I am doing something wrong? As in I thought I
would not be the first to hit this error.
Does anybody have any thoughts or ideas?
Many thanks.
Timothy
-------------- next part --------------
Authenticated to 192.168.1.100 ([192.168.1.100]:22).
debug1: Remote connections from /home/tbrown/.gnupg/S.gpg-agent:-2 forwarded to
local address /home/tbrown/.gnupg/S.gpg-agent.extra:-2
debug3: send packet: type 80
debug1: setting up multiplex master socket
debug3: muxserver_listen: temporary control path
/home/tbrown/.ssh/mux/192.168.1.100_22_tbrown.2EvGYCjVoPNdAIrh
debug2: fd 4 setting O_NONBLOCK
debug3: fd 4 is O_NONBLOCK
debug3: fd 4 is O_NONBLOCK
debug1: channel 0: new [/home/tbrown/.ssh/mux/192.168.1.100_22_tbrown]
debug3: muxserver_listen: mux listener channel 0 fd 4
debug2: fd 3 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IP_TOS 0x20
debug1: deferring postauth fork until remote forward confirmation received
debug1: Entering interactive session.
debug1: pledge: id
debug2: set_control_persist_exit_time: schedule exit in 14400 seconds
debug3: receive packet: type 80
debug1: client_input_global_request: rtype hostkeys-00 at openssh.com want_reply
0
debug3: receive packet: type 4
debug1: Remote: /home/tbrown/.ssh/authorized_keys:1: key options:
agent-forwarding port-forwarding pty user-rc x11-forwarding
debug3: receive packet: type 4
debug1: Remote: /home/tbrown/.ssh/authorized_keys:1: key options:
agent-forwarding port-forwarding pty user-rc x11-forwarding
debug3: receive packet: type 81
debug1: remote forward success for: listen /home/tbrown/.gnupg/S.gpg-agent:-2,
connect /home/tbrown/.gnupg/S.gpg-agent.extra:-2
debug1: All remote forwarding requests processed
debug1: control_persist_detach: backgrounding master process
debug2: control_persist_detach: background process is 85607
debug2: fd 4 setting O_NONBLOCK
debug1: forking to background
debug1: multiplexing control connection
debug3: fd 5 is O_NONBLOCK
debug3: fd 5 is O_NONBLOCK
debug1: channel 1: new [mux-control]
debug3: channel_post_mux_listener: new mux channel 1 fd 5
debug3: mux_master_read_cb: channel 1: hello sent
debug2: set_control_persist_exit_time: cancel scheduled exit
debug3: mux_master_read_cb: channel 1 packet type 0x00000001 len 4
debug2: mux_master_process_hello: channel 1 slave version 4
debug2: mux_client_hello_exchange: master version 4
debug3: mux_client_forwards: request forwardings: 0 local, 1 remote
debug1: Requesting forwarding of remote forward
/home/tbrown/.gnupg/S.gpg-agent:-2 ->
/home/tbrown/.gnupg/S.gpg-agent.extra:-2
debug3: mux_master_read_cb: channel 1 packet type 0x10000006 len 92
debug2: mux_master_process_open_fwd: channel 1: request remote forward
/home/tbrown/.gnupg/S.gpg-agent:-2 ->
/home/tbrown/.gnupg/S.gpg-agent.extra:-2
debug2: mux_master_process_open_fwd: found existing forwarding
debug3: mux_client_request_session: entering
debug3: mux_client_request_alive: entering
debug3: mux_master_read_cb: channel 1 packet type 0x10000004 len 4
debug2: mux_master_process_alive_check: channel 1: alive check
debug3: mux_client_request_alive: done pid = 806
debug3: mux_master_read_cb: channel 1 packet type 0x10000002 len 57
debug2: mux_master_process_new_session: channel 1: request tty 1, X 0, agent 0,
subsys 0, term "rxvt-unicode-256color", cmd "", env 0
debug3: mm_receive_fd: recvmsg: Resource temporarily unavailable
mm_receive_fd: recvmsg: expected received 1 got 0
mux_master_process_new_session: failed to receive fd 0 from slave
debug1: channel 1: mux_rcb failed
debug2: channel 1: zombie
debug2: channel 1: gc: notify user
debug3: mux_master_control_cleanup_cb: entering for channel 1
debug2: channel 1: gc: user detached
debug2: channel 1: zombie
debug2: channel 1: garbage collecting
debug1: channel 1: free: mux-control, nchannels 2
debug3: channel 1: status: The following connections are open:
debug2: set_control_persist_exit_time: schedule exit in 14400 seconds
Abort trap (core dumped)
xps ~$
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ssh.patch
Type: text/x-diff
Size: 702 bytes
Desc: not available
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20190627/b834d9df/attachment.bin>
On Thu, 27 Jun 2019, Timothy Brown wrote:> Hi, > > I posted this question to the OpenBSD bugs list last week, however > I have had no reply and it was suggested on IRC that I post here > instead. So I must apologise if this is not appropriate.Hi - the OpenBSD tech@ mailing list would probably be a better fit for discussions of OpenBSD-only problems (AFAIK nobody else has yet adopted pledge(2) unfortunately). That being said, I'm happy to look at it - but would ask you to send the output of ssh in verbose mode (i.e. "ssh -vvv host") to see exactly where the problem is happening. -d> For a reference here is my previous post: > https://marc.info/?l=openbsd-bugs&m=156080681530337&w=2 > > I am running OpenBSD 6.5-stable (also tested on -current). When I > ssh somewhere I get a sig abort from pledge(). > > I use a Yubikey with GPG and use gpg-agent as my ssh-agent. I also > remote forawrd this agent. For example my .ssh/config has the following > (please note the RemoteForward is actually all on one line, I have split > it here to keep it below 80 chars): > > Host www > Hostname 192.168.1.100 > RemoteForward /home/tbrown/.gnupg/S.gpg-agent \ > /home/tbrown/.gnupg/S.gpg-agent.extra > ExitOnForwardFailure yes > > Host * > ForwardX11 no > Compression yes > ServerAliveInterval 30 > ServerAliveCountMax 4 > ControlMaster auto > ControlPath ~/.ssh/mux/%h_%p_%r > ControlPersist 4h > > If I ssh, for example: > > xps ~$ ssh www > Abort trap (core dumped) > xps ~$ > > I have attached output for when I crank up there verbosity (ssh_verbose.txt), > as it contains long lines. > > Dmesg contains: > > sh[28960]: pledge "sendfd", syscall 28 > > If I `ktrace` ssh, I get the following: > 28960 ssh PLDG sendmsg, "sendfd", errno 1 Operation not permitted > 28960 ssh PSIG SIGABRT SIG_DFL > 28960 ssh NAMI "ssh.core" > > If I add sendfd to the pledge() call, it works. Please see the attached > patch (ssh.patch). However I do not know if this is an acceptable > solution. > > I guess I have to ask if I am doing something wrong? As in I thought I > would not be the first to hit this error. > > Does anybody have any thoughts or ideas? > > Many thanks. > Timothy >
On Fri, Jun 28, 2019 at 01:06:15PM +1000, Damien Miller wrote:> On Thu, 27 Jun 2019, Timothy Brown wrote: > > > Hi, > > > > I posted this question to the OpenBSD bugs list last week, however > > I have had no reply and it was suggested on IRC that I post here > > instead. So I must apologise if this is not appropriate. > > Hi - the OpenBSD tech@ mailing list would probably be a better fit for > discussions of OpenBSD-only problems (AFAIK nobody else has yet adopted > pledge(2) unfortunately).OK, I'll move over there.> > That being said, I'm happy to look at it - but would ask you to send the > output of ssh in verbose mode (i.e. "ssh -vvv host") to see exactly where > the problem is happening. >I thought I added this as an attachment as it goes over 80 characters wide.> > I have attached output for when I crank up there verbosity (ssh_verbose.txt), > > as it contains long lines.I'll in-line it here, so please excuse the excessive width. Regards Timothy Authenticated to 192.168.1.100 ([192.168.1.100]:22). debug1: Remote connections from /home/tbrown/.gnupg/S.gpg-agent:-2 forwarded to local address /home/tbrown/.gnupg/S.gpg-agent.extra:-2 debug3: send packet: type 80 debug1: setting up multiplex master socket debug3: muxserver_listen: temporary control path /home/tbrown/.ssh/mux/192.168.1.100_22_tbrown.2EvGYCjVoPNdAIrh debug2: fd 4 setting O_NONBLOCK debug3: fd 4 is O_NONBLOCK debug3: fd 4 is O_NONBLOCK debug1: channel 0: new [/home/tbrown/.ssh/mux/192.168.1.100_22_tbrown] debug3: muxserver_listen: mux listener channel 0 fd 4 debug2: fd 3 setting TCP_NODELAY debug3: ssh_packet_set_tos: set IP_TOS 0x20 debug1: deferring postauth fork until remote forward confirmation received debug1: Entering interactive session. debug1: pledge: id debug2: set_control_persist_exit_time: schedule exit in 14400 seconds debug3: receive packet: type 80 debug1: client_input_global_request: rtype hostkeys-00 at openssh.com want_reply 0 debug3: receive packet: type 4 debug1: Remote: /home/tbrown/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding debug3: receive packet: type 4 debug1: Remote: /home/tbrown/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding debug3: receive packet: type 81 debug1: remote forward success for: listen /home/tbrown/.gnupg/S.gpg-agent:-2, connect /home/tbrown/.gnupg/S.gpg-agent.extra:-2 debug1: All remote forwarding requests processed debug1: control_persist_detach: backgrounding master process debug2: control_persist_detach: background process is 85607 debug2: fd 4 setting O_NONBLOCK debug1: forking to background debug1: multiplexing control connection debug3: fd 5 is O_NONBLOCK debug3: fd 5 is O_NONBLOCK debug1: channel 1: new [mux-control] debug3: channel_post_mux_listener: new mux channel 1 fd 5 debug3: mux_master_read_cb: channel 1: hello sent debug2: set_control_persist_exit_time: cancel scheduled exit debug3: mux_master_read_cb: channel 1 packet type 0x00000001 len 4 debug2: mux_master_process_hello: channel 1 slave version 4 debug2: mux_client_hello_exchange: master version 4 debug3: mux_client_forwards: request forwardings: 0 local, 1 remote debug1: Requesting forwarding of remote forward /home/tbrown/.gnupg/S.gpg-agent:-2 -> /home/tbrown/.gnupg/S.gpg-agent.extra:-2 debug3: mux_master_read_cb: channel 1 packet type 0x10000006 len 92 debug2: mux_master_process_open_fwd: channel 1: request remote forward /home/tbrown/.gnupg/S.gpg-agent:-2 -> /home/tbrown/.gnupg/S.gpg-agent.extra:-2 debug2: mux_master_process_open_fwd: found existing forwarding debug3: mux_client_request_session: entering debug3: mux_client_request_alive: entering debug3: mux_master_read_cb: channel 1 packet type 0x10000004 len 4 debug2: mux_master_process_alive_check: channel 1: alive check debug3: mux_client_request_alive: done pid = 806 debug3: mux_master_read_cb: channel 1 packet type 0x10000002 len 57 debug2: mux_master_process_new_session: channel 1: request tty 1, X 0, agent 0, subsys 0, term "rxvt-unicode-256color", cmd "", env 0 debug3: mm_receive_fd: recvmsg: Resource temporarily unavailable mm_receive_fd: recvmsg: expected received 1 got 0 mux_master_process_new_session: failed to receive fd 0 from slave debug1: channel 1: mux_rcb failed debug2: channel 1: zombie debug2: channel 1: gc: notify user debug3: mux_master_control_cleanup_cb: entering for channel 1 debug2: channel 1: gc: user detached debug2: channel 1: zombie debug2: channel 1: garbage collecting debug1: channel 1: free: mux-control, nchannels 2 debug3: channel 1: status: The following connections are open: debug2: set_control_persist_exit_time: schedule exit in 14400 seconds Abort trap (core dumped) xps ~$