Ok, this worked last week. Now it doesn't work. Debian Bullseye.
Konqueror, "sftp://other-machine/" doesn't work anymore. I have one machine still using TDE 14.0.13, which I expected to work when the machines I updated to TDE 14.1.0 started acting this way, but no. Now none of them are able to sftp to each other in Konqueror.
Ssh works just fine between the machines. I'm using shared keys, rather than passwords. Could that be the problem?
The error is occurring instead of the pinentry dialog opening up. NB, the pinentry dialog opens just fine for kmail when signing this email.
Suggestions?
Curt-
On Wed May 17 2023 18:57:10 Curt Howland via tde-users wrote:
Ok, this worked last week. Now it doesn't work. Debian Bullseye.
Konqueror, "sftp://other-machine/" doesn't work anymore. I have one machine still using TDE 14.0.13, which I expected to work when the machines I updated to TDE 14.1.0 started acting this way, but no. Now none of them are able to sftp to each other in Konqueror.
Ssh works just fine between the machines. I'm using shared keys, rather than passwords. Could that be the problem?
The error is occurring instead of the pinentry dialog opening up. NB, the pinentry dialog opens just fine for kmail when signing this email.
Suggestions?
What happens if you run sftp from the user (not root) command line?
--Mike
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On Wednesday 17 May 2023, Mike Bird via tde-users was heard to say:
What happens if you run sftp from the user (not root) command line?
ssh and sftp work from the command line just fine. No change.
It only fails in Konqueror.
On Wednesday 17 May 2023, E. Liddell via tde-users was heard to say:
Try the fish protocol instead?
fish:// works just fine, thank you.
I remember finding a list of Konqueror protocols long ago, but this time when I went looking for the list it wasn't obvious.
So I guess I'll use fish:// for now, unless there is particular testing folks want to suggest.
Is anyone else having this problem?
Curt-
- -- You may my glories and my state dispose, But not my griefs; still am I king of those. --- William Shakespeare, "Richard II"
On 2023/05/18 08:35 PM, Curt Howland via tde-users wrote:
On Wednesday 17 May 2023, Mike Bird via tde-users was heard to say:
What happens if you run sftp from the user (not root) command line?
ssh and sftp work from the command line just fine. No change.
It only fails in Konqueror.
On Wednesday 17 May 2023, E. Liddell via tde-users was heard to say:
Try the fish protocol instead?
fish:// works just fine, thank you.
I remember finding a list of Konqueror protocols long ago, but this time when I went looking for the list it wasn't obvious.
So I guess I'll use fish:// for now, unless there is particular testing folks want to suggest.
Is anyone else having this problem?
Curt-
Hi Curt, what TDE version did sftp stop working for you? There was an update for R14.0.13, with a newer sftp implementation based on libssh and backported from kde4. So I am interested in finding out if the problem is new to R14.1.0 or to earlier versions.
Cheers Michele
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On Thursday 18 May 2023, Michele Calgaro via tde-users was heard to say:
what TDE version did sftp stop working for you? There was an update for R14.0.13, with a newer sftp implementation based on libssh and backported from kde4. So I am interested in finding out if the problem is new to R14.1.0 or to earlier versions.
Ah! Both! I have a desktop which is 14.0.13, and two laptops with 14.1.0 which I upgraded last week, it failed trying to go between any of them.
I also tried "sftp://" out to a remote server which uses a password instead of the shared ssh key, and that worked on 14.0.13. I will try it on 14.1.0.... and it worked on 14.1.0 as well.
So in summary, it seems that sftp:// is failing when using shared ssh keys, in both current 14.0.13 and 14.1.0
I hope someone can independently confirm this.
Curt-
- -- You may my glories and my state dispose, But not my griefs; still am I king of those. --- William Shakespeare, "Richard II"
On 2023/05/18 09:27 PM, Curt Howland via tde-users wrote:
On Thursday 18 May 2023, Michele Calgaro via tde-users was heard to say:
what TDE version did sftp stop working for you? There was an update for R14.0.13, with a newer sftp implementation based on libssh and backported from kde4. So I am interested in finding out if the problem is new to R14.1.0 or to earlier versions.
Ah! Both! I have a desktop which is 14.0.13, and two laptops with 14.1.0 which I upgraded last week, it failed trying to go between any of them.
I also tried "sftp://" out to a remote server which uses a password instead of the shared ssh key, and that worked on 14.0.13. I will try it on 14.1.0.... and it worked on 14.1.0 as well.
So in summary, it seems that sftp:// is failing when using shared ssh keys, in both current 14.0.13 and 14.1.0
I hope someone can independently confirm this.
Curt-
Did it work prior to R14.0.13? also, what kind of error message do you get? Do you see anything strange in ~/.xsession-errors? Do you get any CPU going utilization crazy (100%)? What symptoms do you see?
Cheers Michele
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On Thursday 18 May 2023, Michele Calgaro via tde-users was heard to say:
Did it work prior to R14.0.13?
Yes.
also, what kind of error message do you get?
"The process for the sftp://192.168.1.7 protocol died unexpectedly."
Do you see anything strange in ~/.xsession-errors?
On 14.0.13:
[2023/05/18 10:05:38.045] X Error: BadWindow (invalid Window parameter) 3 Major opcode: 19 Minor opcode: 0 Resource id: 0x221032c tdeioslave: ####### CRASH ###### protocol = tdeio_sftp pid = 529431 signal = 11 [ #0 0x00007fa0c782c0c1 in kdBacktrace(int) from /opt/trinity/lib/libtdecore.so.14:0x001280c1 #1 0x00007fa0c7cac42b in TDEIO::SlaveBase::sigsegv_handler(int) from /opt/trinity/lib/libtdeio.so.14:0x001e242b #2 0x00007fa0c6aacd60 in ?? from /lib/x86_64-linux-gnu/libc.so.6:0x00038d60 #3 0x00007fa0c7473dca in TQString::deref() from /lib/x86_64-linux-gnu/libtqt-mt.so.3:0x0051adca #4 0x00007fa0c7473e9c in TQString::operator=(TQString const&) from /lib/x86_64-linux-gnu/libtqt-mt.so.3:0x0051ae9c #5 0x00007fa0c78a8ea9 in KURL::setProtocol(TQString const&) from /opt/trinity/lib/libtdecore.so.14:0x001a4ea9 #6 0x00007fa0c81d5f63 in ?? from /opt/trinity/lib/trinity/tdeio_sftp.so:0x00005f63 #7 0x00007fa0c81d5e2f in ?? from /opt/trinity/lib/trinity/tdeio_sftp.so:0x00005e2f #8 0x00007fa0c4fe8944 in ?? from /lib/x86_64-linux-gnu/libssh.so.4:0x00032944 #9 0x00007fa0c4fe6166 in ssh_pki_import_privkey_base64 from /lib/x86_64-linux-gnu/libssh.so.4:0x00030166 #10 0x00007fa0c4fe6361 in ssh_pki_import_privkey_file from /lib/x86_64-linux-gnu/libssh.so.4:0x00030361 #11 0x00007fa0c4fc7e3b in ssh_userauth_publickey_auto from /lib/x86_64-linux-gnu/libssh.so.4:0x00011e3b #12 0x00007fa0c81d9bad in ?? from /opt/trinity/lib/trinity/tdeio_sftp.so:0x00009bad #13 0x00007fa0c81dd84b in ?? from /opt/trinity/lib/trinity/tdeio_sftp.so:0x0000d84b #14 0x00007fa0c7cb1540 in TDEIO::SlaveBase::dispatch(int, TQMemArray<char> const&) from /opt/trinity/lib/libtdeio.so.14:0x001e7540 #15 0x00007fa0c7cad3b5 in TDEIO::SlaveBase::dispatchLoop() from /opt/trinity/lib/libtdeio.so.14:0x001e33b5 #16 0x00007fa0c81d5cf5 in kdemain from /opt/trinity/lib/trinity/tdeio_sftp.so:0x00005cf5 #17 0x00005589e91dafec in ?? from tdeio_sftp [tdeinit] sftp /tmp/tdesocket-curt/tdelauncher9IBhin.sl:0x00008fec #18 0x00005589e91dc154 in ?? from tdeio_sftp [tdeinit] sftp /tmp/tdesocket-curt/tdelauncher9IBhin.sl:0x0000a154 #19 0x00005589e91dc8fe in ?? from tdeio_sftp [tdeinit] sftp /tmp/tdesocket-curt/tdelauncher9IBhin.sl:0x0000a8fe #20 0x00005589e91d8ead in ?? from tdeio_sftp [tdeinit] sftp /tmp/tdesocket-curt/tdelauncher9IBhin.sl:0x00006ead #21 0x00007fa0c6a97d0a in __libc_start_main from /lib/x86_64-linux-gnu/libc.so.6:0x00023d0a #22 0x00005589e91d98aa in _start from tdeio_sftp [tdeinit] sftp /tmp/tdesocket-curt/tdelauncher9IBhin.sl:0x000078aa ]
Do you get any CPU going utilization crazy (100%)?
No.
What symptoms do you see?
Just the error message in Konqueror: "An error occurred while loading sftp://192.168.1.2: The process for the sftp://192.168.1.2 protocol died unexpectedly."
- -- You may my glories and my state dispose, But not my griefs; still am I king of those. --- William Shakespeare, "Richard II"
On 2023/05/18 11:08 PM, Curt Howland via tde-users wrote:
On 14.0.13:
tdeioslave: ####### CRASH ###### protocol = tdeio_sftp pid = 529431
Clearly the tdeio_sftp process crashed. Are you able to install tdebase debug symbols and post a new backtrace of a crash, possibly using R14.1.0? That will help reducing the scope of search. Thanks Michele
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On Thursday 18 May 2023, Michele Calgaro via tde-users was heard to say:
Clearly the tdeio_sftp process crashed. Are you able to install tdebase debug symbols
tdebase-trinity-dbg now install.
and post a new backtrace of a crash, possibly using R14.1.0?
Upgrade to 14.1.0 competed, machine power cycled.
Now, how do I get that "backtrace"? I assume it's not just from .xsession-errors this time?
Curt-
- -- You may my glories and my state dispose, But not my griefs; still am I king of those. --- William Shakespeare, "Richard II"
On Thursday 18 of May 2023 18:00:39 Curt Howland via tde-users wrote:
On Thursday 18 May 2023, Michele Calgaro via tde-users was heard to
say:
Clearly the tdeio_sftp process crashed. Are you able to install tdebase debug symbols
tdebase-trinity-dbg now install.
and post a new backtrace of a crash, possibly using R14.1.0?
Upgrade to 14.1.0 competed, machine power cycled.
Now, how do I get that "backtrace"? I assume it's not just from .xsession-errors this time?
Curt-
In the last crash, backtrace was written in ~/.xsession-errors. Therefore, I assume that if the crash is repeated, it should be written there again. Thanks to the debug symbols there instead of "??" should be more accurate information.
Cheers Slávek --
On Thursday 18 of May 2023 13:35:15 Curt Howland via tde-users wrote:
On Wednesday 17 May 2023, Mike Bird via tde-users was heard to say:
What happens if you run sftp from the user (not root) command line?
ssh and sftp work from the command line just fine. No change.
It only fails in Konqueror.
On Wednesday 17 May 2023, E. Liddell via tde-users was heard to say:
Try the fish protocol instead?
fish:// works just fine, thank you.
I remember finding a list of Konqueror protocols long ago, but this time when I went looking for the list it wasn't obvious.
So I guess I'll use fish:// for now, unless there is particular testing folks want to suggest.
Is anyone else having this problem?
Curt-
I would rather ask: After upgrade R14.0.13 => R14.1.0 you did at least logout / login?
Cheers
On Wed, 17 May 2023 21:57:10 -0400 Curt Howland via tde-users users@trinitydesktop.org wrote:
Ok, this worked last week. Now it doesn't work. Debian Bullseye.
Konqueror, "sftp://other-machine/" doesn't work anymore. I have one machine still using TDE 14.0.13, which I expected to work when the machines I updated to TDE 14.1.0 started acting this way, but no. Now none of them are able to sftp to each other in Konqueror.
Ssh works just fine between the machines. I'm using shared keys, rather than passwords. Could that be the problem?
The error is occurring instead of the pinentry dialog opening up. NB, the pinentry dialog opens just fine for kmail when signing this email.
Suggestions?
Try the fish protocol instead?
E. Liddell
-
Curt Howland -
E. Liddell -
Michele Calgaro -
Mike Bird -
Slávek Banko