Slow saml2aws response over ssh

[runultra]

I upgraded to 2.23 today and noticed that over SSH when I run saml2aws login that it takes 2 minutes and 33 seconds before it prompts me to enter my username and password. Any command of saml2aws takes 2+ minutes before I get a response over SSH. if I am local it is instant.

I've seen several comments about keychain, etc.. But I see no actual fix, I'll revert back to 2.14 as the bug is not an issue there. Can We get this looked at? I've also tried initiating it with --disable-keychain and still the issue remains.

[runultra]

Any update on this?

[tbugfinder]

Hi, I see that same issue. Would a strace output be helpful?

I'm using version 2.25

$ time ./saml2aws login credentials are not expired skipping

real 2m0.095s user 0m0.016s sys 0m0.031s

[tbugfinder]

My strace shows a lot of dbus output. Was this PR backed out or is there still a dependancy to dbus? https://github.com/Versent/saml2aws/pull/210

I switched to a desktop environment and I'm able to run 2.25 successfully. Is there any thought if a console only execution with latest versions might be possible again?

[runultra]

@tbugfinder I've been able to get around it by running saml2aws via DBUS_SESSION_BUS_ADDRESS=/dev/null saml2aws login with the help from a co-worker for finding this workaround. I've added an alias to run saml2aws that way and it works, but it's not ideal.

[cpitstick-argo]

Seeing this as well, also confirmed workaround. Please fix.

[BruXy]

Hi, I am glad it is reported, I have found the same issue. I have version 2.26.1, connected over ssh -Y and X forwarding is working normally. All operations have taken 2 minutes before setting DBUS_SESSION_BUS_ADDRESS=/dev/null. When I am running strace, it is getting stuck around this point:

socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 11
setsockopt(11, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0
connect(11, {sa_family=AF_LOCAL, sun_path=@"/tmp/dbus-3q0mvsOd9d"}, 23) = 0
epoll_ctl(8, EPOLL_CTL_ADD, 11, {EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, {u32=3301511016, u64=140642005618536}}) = 0
getsockname(11, {sa_family=AF_LOCAL, NULL}, [2]) = 0
getpeername(11, {sa_family=AF_LOCAL, sun_path=@"/tmp/dbus-3q0mvsOd9d"}, [23]) = 0
getuid()                                = 1001
getpid()                                = 28043
getuid()                                = 1001
getgid()                                = 1001
sendmsg(11, {msg_name(0)=NULL, msg_iov(1)=[{"\0", 1}], msg_controllen=32, [{cmsg_len=28, cmsg_level=SOL_SOCKET, cmsg_type=SCM_CREDENTIALS, {pid=28043, uid=1001, gid=1001}}],
 msg_flags=0}, 0) = 1
write(11, "AUTH\r\n", 6)                = 6
read(11, "REJECTED EXTERNAL DBUS_COOKIE_SH"..., 4096) = 46
write(11, "AUTH EXTERNAL 31303031\r\n", 24) = 24
read(11, "OK 76bf5caf4622a2cdee76fc9d5f19c"..., 4096) = 37
write(11, "NEGOTIATE_UNIX_FD\r\n", 19)  = 19
read(11, 0xc00027f000, 4096)            = -1 EAGAIN (Resource temporarily unavailable)
read(11, "AGREE_UNIX_FD\r\n", 4096)     = 15
write(11, "BEGIN\r\n", 7)               = 7
futex(0xc000080148, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0xc00001ebc8, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x1136328, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
futex(0xc00001ebc8, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0xc000080148, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x1136328, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
futex(0xc00001e848, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x1136328, FUTEX_WAIT_PRIVATE, 0, NULL

[tbugfinder]

Hi @wolfeidau, in terms of help - which direction should the PR targeting? Are there any thoughts or if this up to the coder?

[ckarmann]

Hello, I had the same problem. I found that the environment variable $DISPLAY was set to a wrong value in my environment. unset DISPLAY fixes saml2aws. I don't know what is the link between them but it seems saml2aws uses $DISPLAY for something and stalls if the IP is unreachable.

[Killea]

@tbugfinder I've been able to get around it by running saml2aws via DBUS_SESSION_BUS_ADDRESS=/dev/null saml2aws login with the help from a co-worker for finding this workaround. I've added an alias to run saml2aws that way and it works, but it's not ideal.

nice. worked for my WSL2.

[injectedfusion]

@tbugfinder I've been able to get around it by running saml2aws via DBUS_SESSION_BUS_ADDRESS=/dev/null saml2aws login with the help from a co-worker for finding this workaround. I've added an alias to run saml2aws that way and it works, but it's not ideal.

nice. worked for my WSL2.

this worked for my WSL2 as well.

[catterad]

@tbugfinder I've been able to get around it by running saml2aws via DBUS_SESSION_BUS_ADDRESS=/dev/null saml2aws login with the help from a co-worker for finding this workaround. I've added an alias to run saml2aws that way and it works, but it's not ideal.

I found that setting this as a environment var worked for me. I'm not familiar with DBUS_SESSION_BUS_ADDRESS and its use to know if this impacts other things, but its a work around that doesn't need an alias..

E.g.

export DBUS_SESSION_BUS_ADDRESS=/dev/null or export DBUS_SESSION_BUS_ADDRESS=unix