Weirdly behaving Copy and Paste password when logging with SSH

Hello everyone!

Today I have noticed quite strange behaviour when setting up server in my home lab running Rocky Linux. When I changed the password for SSH login account on the server and saved it to my password manager (BitWarden) I had no problems using the password for sudo and logging into the server repeatedly copy and pasting it, that was until I restarted the server.

Since I had several problems with the server already I thought its just another one and remade it onto Debian 12. But the same problem occured, copy and pasting correct password returned “Permission denied, please try again.” from my testing, it for some time seemed might have been password length problem. But then I took the time and rewritten my 40 character random password by hand and I logged in again! After that when I logged out I could even copy and paste the SSH password from BitWarden without any issues, unless I restarted the server OR tried different terminal application.
Then it did not work unless I typed the password by hand again.

I am on Tumbleweed, Wayland using KDE Plasma 6.2.5.
SSH version is OpenSSH_9.9p1, OpenSSL 3.2.3 3 Sep 2024
I have tried on Konsole 24.12.0 and Xterm

If anyone has any idea on how to debug it I will be glad to try out!

It’s a bit hard to guess what is going wrong. Copy/paste might be changing some characters. For example, it will change a TAB to spaces.

2 Likes

Compare ssh -vvv in bad and good cases.

strace ssh to check whether password it gets from pasting is correct.

1 Like

I have compared those two. But I do not see anything weird except bad password inputed in the not working case and correct password inputted and connection established in the working case.

This helped me more and thanks for recommending that, it was exactly what I needed to see the actual password. Although I still can not make yet out why it behaves like that.

For some reason when I try to connect first time to the server, the password starts with

read(4, "[", 1)                         = 1
read(4, "2", 1)                         = 1
read(4, "0", 1)                         = 1
read(4, "0", 1)                         = 1
read(4, "~", 1)                         = 1

sequence, but the moment I successfully connect and disconnect, doing exactly the same steps, meaning.

  1. Opening password manager
  2. Opening the information I saved for this server
  3. Clicking copy next to password in the UI (tried even selecting and pressing control + C)
  4. Pasting the password into terminal when prompted for password.

This starting sequence just disapears and it pastes password in correct format unless the server is restarted again.

I have found out it has to do with bracketed pasting and it seems to work properly when I use set enable-bracketed-paste Off command in my terminal.

I still do not understand why the behaviour changes after connecting to the ssh correctly for the first time tho. I would be glad for any idea on hwo to figure more out or explanation of this behaviour if it is known already.
Thank you very much!

From man 1 bind:

   enable-bracketed-paste (On)
          When set to On, readline configures the terminal to insert each paste into the editing buffer as a single string of characters, instead of treating each character as if it had been read from
          the keyboard.  This prevents readline from executing any editing commands bound to key sequences appearing in the pasted text.

So, “this prevents”, the problem seems to be something bound to the password key sequence.

No. The password starts with ESC:

read(0, "\33", 1)                       = 1

Be precise in the information you provide.

Again - be precise in the information you provide. It is not “your terminal”. It is the shell you are using and you did not tell which shell it is. The bash most certainly does not know such command (or, better, using this command in bash has no effect).

At this point it should be fairly obvious that bracketed paste gets disabled for the terminal emulator where you run ssh when you login to the remote server by the program (shell) started there. You can verify it by straceing ssh and checking what gets sent to the stdout/stderr (or - to be absolutely sure - by straceing your login sequence on the remote server).

More practical question is - why bracketed paste is not disabled when your shell starts external command. bash does disable it and reenables again after the external command exits.

andrei@tumbleweed:~> grep -E 'write|clone' /tmp/foo
...
write(2, "\33[?2004l\r", 9)             = 9
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f3bcc22f8d0) = 5264
wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], WSTOPPED|WCONTINUED, NULL) = 5264
write(2, "\33[?2004h", 8)               = 8
...
andrei@tumbleweed:~>

But again, you did not tell what shell you were using …

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.