[GH-ISSUE #587] Option for manual password input

kerem commented

2026-03-01 17:20:15 +03:00

Owner

Originally created by @LadderOperator on GitHub (Dec 10, 2023).
Original GitHub issue: https://github.com/1Remote/1Remote/issues/587

Originally assigned to: @VShawn on GitHub.

Is your feature request related to a problem? Please describe.
In some cases password is integrated with TOTP and private key is not supported for safety, so we need to input different password every time. In current version, only one 'static' password can be set in configuration, which will be denied obviously.

After that, I need to input my correct password in the terminal. Additionally, this problem causes unsuccessful login of SFTP at the same time.

Describe the solution you'd like
An option like "Manual input" for password could be considered: when this option was checked and user ran an SSH session, 1Remote would popup a dialog waiting for user to input password manually. If SFTP was needed, after successful SSH login the password would be passed to SFTP as well.

In fact it sounds like what XShell does

Originally created by @LadderOperator on GitHub (Dec 10, 2023). Original GitHub issue: https://github.com/1Remote/1Remote/issues/587 Originally assigned to: @VShawn on GitHub. **Is your feature request related to a problem? Please describe.** In some cases password is integrated with TOTP and private key is not supported for safety, so we need to input different password every time. In current version, only one 'static' password can be set in configuration, which will be denied obviously. ![image](https://github.com/1Remote/1Remote/assets/34033754/e648aa15-ab84-4d78-b8cd-bd17bbc7d9b9) After that, I need to input my correct password in the terminal. Additionally, this problem causes unsuccessful login of SFTP at the same time. **Describe the solution you'd like** An option like "Manual input" for password could be considered: when this option was checked and user ran an SSH session, 1Remote would popup a dialog waiting for user to input password manually. If SFTP was needed, after successful SSH login the password would be passed to SFTP as well. In fact it sounds like what XShell does ![image](https://github.com/1Remote/1Remote/assets/34033754/6537d93f-7d99-475d-8b12-6794bbead2e9)

kerem

2026-03-01 17:20:15 +03:00

closed this issue
added the
meta-feature

area-ct-ssh
labels

kerem commented

2026-03-01 17:20:16 +03:00

Author

Owner

@VShawn commented on GitHub (Jan 2, 2024):

humm... it's difficult to achieve because SSH is controlled by Kitty. The only thing 1Remote does is open a kitty process, 1Remote cannot determine whether the SSH inside this process requires a second password input.

It is possible to achieve this by integrating a modified version of Kitty into 1Remote. However, I personally do not have enough time to undertake this task.

@VShawn commented on GitHub (Jan 2, 2024): humm... it's difficult to achieve because SSH is controlled by Kitty. The only thing 1Remote does is open a kitty process, 1Remote cannot determine whether the SSH inside this process requires a second password input. It is possible to achieve this by integrating a modified version of Kitty into 1Remote. However, I personally do not have enough time to undertake this task.

kerem commented

2026-03-01 17:20:16 +03:00

Author

Owner

@LadderOperator commented on GitHub (Jan 4, 2024):

humm... it's difficult to achieve because SSH is controlled by Kitty. The only thing 1Remote does is open a kitty process, 1Remote cannot determine whether the SSH inside this process requires a second password input.

It is possible to achieve this by integrating a modified version of Kitty into 1Remote. However, I personally do not have enough time to undertake this task.

Thanks for your work anyway. This app is very helpful.

In fact what I mean is:

Add a "manually enter password" option in the profile. If you check this option, you will be required to enter the password manually every time you open a session.
(based on the first step): At the same time, use the SSH password to connect to SFTP without checking. If the time interval is short enough (everything is done before TOTP refreshed), you can log in to both SSH and SFTP (almost) at once. This avoids modifying Kitty, though it looks not clever. "If SFTP was needed, after successful SSH login the password would be passed to SFTP as well." is unrealistic , just forget it...

@LadderOperator commented on GitHub (Jan 4, 2024): > humm... it's difficult to achieve because SSH is controlled by Kitty. The only thing 1Remote does is open a kitty process, 1Remote cannot determine whether the SSH inside this process requires a second password input. > > It is possible to achieve this by integrating a modified version of Kitty into 1Remote. However, I personally do not have enough time to undertake this task. Thanks for your work anyway. This app is very helpful. In fact what I mean is: 1. Add a "manually enter password" option in the profile. If you check this option, you will be required to enter the password manually every time you open a session. 2. (based on the first step): At the same time, use the SSH password to connect to SFTP without checking. If the time interval is short enough (everything is done before TOTP refreshed), you can log in to both SSH and SFTP (almost) at once. This avoids modifying Kitty, though it looks not clever. "If SFTP was needed, after successful SSH login the password would be passed to SFTP as well." is unrealistic , just forget it...

kerem commented

2026-03-01 17:20:16 +03:00

Author

Owner

@majkinetor commented on GitHub (Jan 8, 2024):

Add a "manually enter password" option in the profile. If you check this option, you will be required to enter the password manually every time you open a session.

What is the problem with leaving the password empty? You will get asked each time.

If SFTP was needed, after successful SSH login the password would be passed to SFTP as well.

Can you explain this a little bit?

@majkinetor commented on GitHub (Jan 8, 2024): > Add a "manually enter password" option in the profile. If you check this option, you will be required to enter the password manually every time you open a session. What is the problem with leaving the password empty? You will get asked each time. > If SFTP was needed, after successful SSH login the password would be passed to SFTP as well. Can you explain this a little bit?

kerem commented

2026-03-01 17:20:16 +03:00

Author

Owner

@LadderOperator commented on GitHub (Jan 9, 2024):

Add a "manually enter password" option in the profile. If you check this option, you will be required to enter the password manually every time you open a session.

What is the problem with leaving the password empty? You will get asked each time.

If SFTP was needed, after successful SSH login the password would be passed to SFTP as well.

Can you explain this a little bit?

The first question, yes, you are right. I do get asked every time after the "permission denied" s from the KiTTY process if I leave the password empty (actually this is the way I use 1Remote currently). However, as @VShawn mentioned above,

1Remote cannot determine whether the SSH inside this process requires a second password input
If I use SSH only, there is no problem. Whether 1Remote knows the password I input is not important.

But if I want to use SFTP at the same time (with the same TOTP password), 1Remote will open an SFTP session with a red "permission denied" (this is expected since my password is empty) on the bottom and there is no second chance for password input.

Since 1Remote cannot determine whether the SSH login was successful, I think it could be better to add a "manually enter password" option in the profile. The difference is that, with this option checked, user inputs password in a dialog box of 1Remote before SSH session is started instead of in the KiTTY process. Then 1Remote will get the password and send it to SFTP directly, without validation. We can expect two cases:

If the password is wrong, SSH login fails and a second password input will be required as it does in current version. SFTP login is still raising error.
If the password is correct, SSH login succeeds and SFTP login will be successful at the same time (If the password is not expired).

@LadderOperator commented on GitHub (Jan 9, 2024): > > Add a "manually enter password" option in the profile. If you check this option, you will be required to enter the password manually every time you open a session. > > What is the problem with leaving the password empty? You will get asked each time. > > > If SFTP was needed, after successful SSH login the password would be passed to SFTP as well. > > Can you explain this a little bit? The first question, yes, you are right. I do get asked every time after the "permission denied" s from the KiTTY process if I leave the password empty (actually this is the way I use 1Remote currently). However, as @VShawn mentioned above, > 1Remote cannot determine whether the SSH inside this process requires a second password input If I use SSH only, there is no problem. Whether 1Remote knows the password I input is not important. But if I want to use SFTP at the same time (with the same TOTP password), 1Remote will open an SFTP session with a red "permission denied" (this is expected since my password is empty) on the bottom and there is no second chance for password input. Since 1Remote cannot determine whether the SSH login was successful, I think it could be better to add a "manually enter password" option in the profile. The difference is that, with this option checked, user inputs password in a dialog box of 1Remote before SSH session is started instead of in the KiTTY process. Then 1Remote will get the password and send it to SFTP directly, without validation. We can expect two cases: 1. If the password is wrong, SSH login fails and a second password input will be required as it does in current version. SFTP login is still raising error. 2. If the password is correct, SSH login succeeds and SFTP login will be successful at the same time (If the password is not expired).

kerem commented

2026-03-01 17:20:16 +03:00

Author

Owner

@majkinetor commented on GitHub (Jan 9, 2024):

But if I want to use SFTP at the same time

I understand your point, I am just not sure how do you "use SFTP at the same time" ? SSH and SFTP are separate connection types in 1Remote. Do you actually just use SFTP connection and expect that behavior from it ?

@majkinetor commented on GitHub (Jan 9, 2024): > But if I want to use SFTP at the same time I understand your point, I am just not sure how do you "use SFTP at the same time" ? SSH and SFTP are separate connection types in 1Remote. Do you actually just use SFTP connection and expect that behavior from it ?

kerem commented

2026-03-01 17:20:16 +03:00

Author

Owner

@majkinetor commented on GitHub (Jan 9, 2024):

Besides,

@VShawn

1Remote cannot determine whether the SSH inside this process requires a second password input.

But in any case, this might be feasible as kitty has integrated scripting, so I am 99% sure no kitty modification is required.

@majkinetor commented on GitHub (Jan 9, 2024): Besides, @VShawn > 1Remote cannot determine whether the SSH inside this process requires a second password input. But in any case, this might be feasible as kitty has integrated scripting, so I am 99% sure no kitty modification is required.

kerem commented

2026-03-01 17:20:16 +03:00

Author

Owner

@VShawn commented on GitHub (Jan 13, 2024):

In this case, we do not need to add the "manually enter password".

what needs to be improved is the default behavior of SFTP. When starting SFTP, if the password is empty, it should prompt the user to enter the password instead of directly logging in with an empty password.

@VShawn commented on GitHub (Jan 13, 2024): In this case, we do not need to add the "manually enter password". what needs to be improved is the default behavior of SFTP. When starting SFTP, if the password is empty, it should prompt the user to enter the password instead of directly logging in with an empty password.

Rows
Columns

[GH-ISSUE #587] Option for manual password input #2396