Freerdp: Feature Request: GUI Prompt for Password

[jar349]

Love xfreerdp! I've created a script for each of the machines that I often RDP into, so I now have quick access to them!

I'd like to be able to launch these scripts in the command box I get when I press ALT+F2 in linux. Now, if I set my script to be "xfreerdp $@", then I can call my script and add /p: as an argument and it works great.

The problem is that anyone sitting next to me will see my password. I'd love for xfreerdp to popup a GUI prompt for my password so that it's not visible as I type it. Is that already possible somehow? If so, I'm sorry for this issue - but I couldn't find it.

If it's not already possible, would you please consider it as a feature request?

[macarthor]

what language you're writing your script with? if you're using python, just use "getpass" library which would prompt you to input password and the password is hidden on screen, and then you can pass the password to freerdp. Other language such as bash should has such feature either.

[jar349]

I'm using bash. I'm going to try this: http://stackoverflow.com/questions/3980668/how-to-get-a-password-from-a-shell-script-without-echoing. I'll let you know how it goes.

But still, this will only work in my command-line. I couldn't create a launcher on my desktop because it doesn't have a standard input to read from, at least not one that's accessible to the user.

[hashstat]

The problem with providing passwords on the command-line is that they immediately become available to other users on the system. Even if you use tricks to mask password entry, the entire command-line is available via ps or /proc/$PID/cmdline.

What is needed is something like what ssh does:

If ssh needs a passphrase, it will read the passphrase from the
current terminal if it was run from a terminal. If ssh does not
have a terminal associated with it but DISPLAY and SSH_ASKPASS
are set, it will execute the program specified by SSH_ASKPASS
and open an X11 window to read the passphrase. This is particu‐
larly useful when calling ssh from a .xsession or related
script. (Note that on some machines it may be necessary to re‐
direct the input from /dev/null to make this work.)

Perhaps we need a FREERDP_ASKPASS environment variable. If it isn't defined, it could try SSH_ASKPASS. Or perhaps FreeRDP should just open a window itself to ask for the username and password. It would also be nice to display and resolve certificate issues from the GUI.

[roysjosh]

For me, this is a needed feature for work. Any time I get setup with a new Windows account, I attempt to RDP via xfreerdp to it and it fails. After bugging the admin, I discover they have set the "change password on first login" attribute. xfreerdp makes this look like an SSL error or that maybe the admin hasn't given me the correct initial credentials:
Password:
SSL_read: Failure in SSL library (protocol error?)
Authentication failure, check credentials.
If credentials are valid, the NTLMSSP implementation may be to blame.

I have to switch back to rdesktop to bring up the GUI login which then allows me to change my password. I imagine that in 180 days when my passwords expire I'll have the same issue.

[awakecoding]

@roysjosh to do the equivalent of "switching back to rdesktop" to change the password, you just need to disable NLA in FreeRDP. Use /sec:tls to force TLS security.

[roysjosh]

Oh, nice, thanks. I wasn't really sure what NLA was or why it was relevant in the above posts.

[awakecoding]

@roysjosh I'd be curious to really know how mstsc behaves when the password needs to be changed with NLA. There's a hole in the specs about this specific case.

[bmiklautz]

@awakecoding for nla you can't change the password: http://support.microsoft.com/kb/2648397

[awakecoding]

@bmiklautz wow. that is so retarded. oh well, we can't really do any better than mstsc then.

[ondrejholy]

I see in the source codes that e.g. Windows or Mac clients have GUI prompt for authentication. Is there any reason why X11 doesn't have any? It is pretty uncomfortable and insecure to specify password on the commandline everytime.

Would be best to show login screen like in TLS case, but with NLA there isn't any "replacement" for it, am I right?

I'd like to integrate xfreerdp more in to the desktop. I've been thinking about intergration with standardized freedesktop secret service or/and gnome-online-accounts, possibly with gtk dialogs for authentication and verifying certificates.

Do you like this idea, or have another one?

[bmiklautz]

@ondrejholy the password should get replaced with * so in the process list you should only see /p:** (in the password was pass). Only down side is that the password length is known.
If you just don't supply a password vi /p you get asked on the terminal when connecting.
For sure this isn't really optimal when you want GUI only.

xfreerdp only uses plain Xlib and therefore it it's quite a lot of work to write an input fields or something like buttons. So it's not a technical reason that there is no GUI prompt for xfreerdp just that nobody was in mood or had time to implement it (pull requests are very welcome :).

If you don't mind having an extra terminal and use gnome desktop files you can try running xfreerdp in a terminal instead of directly and just don't supply the password. Then the terminal shows the password prompt.
Another possible solution (that definitely works for version 1.0.x but might not work for latest master at the moment) is to write a script that queries the password (e.g. with zenity) and then use the command line parameter --from-stdin. For example:

echo -e "user\npassword\ndomain\nhostname" | xfreerdp --from-stdin

In this case the password is never shown in the process list.

[bmiklautz]

@ondrejholy as for replacing the password with * there is currently an issue on master see #2252

[ondrejholy]

@bmiklautz I like to hear that you would like to have gui for xfreerdp. I did already something with plain Xlib (it is like reinventing the wheel), so I could refresh my knowledges... Don't you want to use any toolkit for it?

Yes, I can make some scripts to get password from keyring and put in on stdin for example, but would be nice to have it in freerdp. I'd like to be gnome-online-accounts supported by xfreerdp at the best, but I suppose you don't want to add dependencies on g-o-a, am I right?

[bmiklautz]

@ondrejholy yeah with Xlib it's really like reinventing the wheel ("quite" a pain :).
But the problem with using a toolkit is that it introduces and extra dependency. If we make it optional (e.g. configurable at compile time) it should be fine but I personally wouldn't like to have a fixed "big" dependency to gtk,qt,...

[mjevans]

What I would really prefer is the ability to specify credentials from files. This way using a secure folder ( E.G. $XDG_RUNTIME_DIR as specified in http://www.freedesktop.org/software/systemd/man/pam_systemd.html ) it is possible to provide credential information in a way which is not accessible by other user's processes.

[hashstat]

I agree with @mjevans. Reading from a file could be made more secure than from the command-line or environment variables. One could even use a fifo (named pipe) or bash magic (process substitution) to call a generic GUI prompter for the password and pass it to freerdp via the file. The simplest approach would be to read a single line from the file and use it for authentication. What would be even better is to find some way to signal an unsuccessful attempt and then read another line. Another file might be required for that.

[ghost]

Any news on this?

As a workaround, I wrote the following script. Been using it for some time, a bit hacky but works like a charm. (You need , a fork of Zenity that provides much more functionality, and xdotool for this)

Hope someone finds it useful! Cheers!

#!/bin/bash

AUDIO=
DOWNS=
USB=
USER=
DOMAIN="MyDomain"
SERVER="10.20.30.40"
GEOMETRY="/f"


while [ -n "$1" ]
do
    case "$1" in
        --USB)
            USB="/drive:USB,/media/user"
            ;;
        --downloads)
            DOWNS="/drive:Downloads,$HOME/Downloads"
            ;;
        --audio)
            AUDIO="/sound"
            ;;
        -g)
            shift
            [[ ! $1 =~ ^[0-9]{3,4}x[0-9]{3,4}$ ]] && echo "Invalid resolution, defaulting to fullscreen." && continue
            GEOMETRY=$(echo $1 | awk -Fx '{ printf("/w:"$1" /h:"$2); }')
            ;;
        *)
            [ "${1:0:1}" != "-" ] && USER=$1
    esac
    shift
done


while true
do

[ -n "$USER" ] && until xdotool search "Terminal server login" windowactivate key Right Tab 2>/dev/null ; do sleep 0.05; done &

FORM=$(yad --center --width=380 \
    --window-icon="gtk-execute" --image="gcr-password"\
    --title "Terminal server login" \
    --form --field="User name" "$USER"\
    --field="Password":H)

[ $? != 0 ] && exit

USER=$(echo $FORM | awk -F '|' '{ print $1 }')
PASS=$(echo $FORM | awk -F '|' '{ print $2 }')

RES=$(xfreerdp /v:"$SERVER" /cert-ignore /sec-tls $GEOMETRY /d:"$DOMAIN" /u:"$USER" /p:"$PASS" +compression +clipboard -menu-anims +fonts $USB $DOWNS $AUDIO 2>&1)

echo $RES | grep -q "Authentication failure" && yad --center --image="error" --window-icon="error" --title "Authentication failure" --text="Please make sure you typed\nyour password correctly." --text-align=center --width=320 --button=gtk-ok --buttons-layout=spread && continue

echo $RES | grep -q "connection failure" && yad --center --image="error" --window-icon="error" --title "Connection failure" --text="Could not connect to the server.\n\nPlease check your network connection." --text-align=center --width=320 --button=gtk-ok --buttons-layout=spread

break
done

[ondrejholy]

I don't think there are any news about this (at least not from my side), however you might also use some external tools (e.g. Remmina, Vinagre) to manage your connections...

[AeliusSaionji]

Try using dmenu:

#!/bin/sh
# Use echo to populate dmenu's selection list
machine=$(echo -e "preset1\npreset2\npreset3" | dmenu -l 5 -p "Choose a host")
user=$(echo -e "Link\nBob\nMark" | dmenu -l 5 -p "Username:")
# Set background and foreground colors the same to mask password input
pass=$(echo "..." | dmenu -p "Password:" -nb "#222222" -nf "#222222")

# Define presets
case $machine in
    "preset1")
        echo $pass | xfreerdp /v:192.168.1.101 /u:$user /from-stdin /workarea /rfx +home-drive ;;
    "preset2")
        echo $pass | xfreerdp /v:127.0.0.1     /u:$user /from-stdin /workarea -compression +clipboard ;;
    "preset3")
        echo $pass | xfreerdp /v:example.com   /u:$user /from-stdin /workarea ;;
esac

[rkeene]

This doesn't really help since if yo use "from-stdin" you are not able to accept the certificate of the remote host.

The above X.509 certificate could not be verified, possibly because you do not have the CA certificate in your certificate store, or the certificate has expired. Please look at the documentation on how to create local certificate store for a private CA.
Do you trust the above certificate? (Y/N) 
Error: Could not read answer from stdin. - Run without parameter "--from-stdin" to set trust.

[wyllianbs]

xfreerdp-gui

URL: https://github.com/wyllianbs/xfreerdp-gui

Adapted from: https://github.com/FreeRDP/FreeRDP/issues/1358#issuecomment-175075061

[Jackfritt]

Try this.
xfreerdp /v:example.com /d:DOMAIN /u:User +clipboard -themes -wallpaper /drives /cert-ignore /w:2560 /h:1350 /p:$(kdialog --password "Please enter RDP Password")
You can add this to an KDE Desktop file like:
[Desktop Entry]
Categories=
Comment[de_DE]=Connect to Client
Comment=Connect to Client
Exec=xfreerdp /v:example.com /d:DOMAIN /u:User +clipboard -themes -wallpaper /drives /cert-ignore /w:2560 /h:1350 /p:$(kdialog --password "Please enter RDP Password")

kdialog is for KDE, maybe you need xdialog or zenity for other display Managers?

[Jogai]

@Jackfritt Yes, for lxqt I used qarma succesfully

[vermgit]

I don't know if it helps in all situations (and I hope it's on-topic :) ), but I also didn't like the password in the command line. However, I learned that I can use /sec:tls instead of the /p-switch, which at least helps when connecting to Windows machines. What it does is it shows the typical Windows login form where you enter the password as you'd be when sitting in front of the machine. You can still preset the username with /u.

Maybe a different approach to the matter...