Created attachment 1383 [details] modifies gnome-ssh-askpass2.c to use one-time password Patch modifies gnome-ssh-askpass to optionally generate a one-time password and transmit it via an out-of-band communication channel. If you can read the password and enter it back into the gnome-ssh-askpass dialog, ssh-agent is allowed to continue with the authentication process. There are two ways to use the modified gnome-ssh-askpass. The first method incrementally increases the security provided by the ssh-agent/gnome-ssh-askpass combination. The second allows you to create two fully separated authentication factors - the private key and one-time password - without using a specialized hardware token. Please see the README (www.swcp.com/~pgsery) for a detailed explanation and examples.
Created attachment 1384 [details] Describes patch and provides examples
Comment on attachment 1383 [details] modifies gnome-ssh-askpass2.c to use one-time password >+#define OTAC_FIFO_LEN 32 /* max fifo name length */ This should probably be MAXPATHLEN, (however see next comment). >+ /* generate and transmit otac passphrase if env var set */ >+ otac_fifo=malloc(OTAC_FIFO_LEN); >+ otac_fifo=getenv("SSH_OTAC_FIFO"); You malloc otac_fifo, then immedately overwrite it with the return value from getenv. The malloc is unnecessary (and a memory leak). >+char * >+write_otac_to_fifo(char *otac_fifo) Since this is not exported, you can declare it static like the existing functions. Also, if you move it to before its caller you will not need a declaration line for it. >+ int i,ran,nchars=52,otac_length=OTAC_PWD_LEN; >+ char cpool[52]="abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ"; The "52" is a magic number. You can do without it by doing something like: char cpool[]="abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ"; size_t nchars = sizeof(cpool) - 1; >+ srandom(time(0)); The time is not a secret. You should use arc4random instead of random. The downside of that is that you will need to link with libopenbsd-compat, libssh and libcrypto on platforms that do not have a native arc4trandom. Native arc4random does not require seeding, and the one in the compat library will seed itself if required. >+ otac_passphrase=malloc(otac_length+1); The return value of the malloc is not being checked for failure. >+ for (i=0;i<otac_length;i++) { >+ ran = random(); >+ otac_passphrase[i]=cpool[ran%nchars]; Because 2^32 is not divisible by nchars, the passphrase will have a tiny bias. >+ otac_passphrase[otac_length] = 0; Nit: strings are terminated by '\0' not 0. >+ /* write otac password to fifo */ >+ if ( (out=fopen(otac_fifo,"w")) == NULL) { >+ mkfifo(otac_fifo, 0660); >+ out=fopen(otac_fifo,"w"); >+ } There is no guarantee that this ends up opening the fifo. The first fopen can fail for some reason other than the fifo not existing (eg permissions). The mkfifo could also fail (permissions again) and the second fopen could also fail (eg permissions, or a race). You might also like to match the format of the existing code better as it makes it easier to read (eg spaces between terms).
Created attachment 1390 [details] Updated gnome-ssh-askpass2.c/otac patch Replaced random number generator placeholder with arc4random Added arc4random dependencies to contrib gnome-ssh-askpass Makefile General clean-up
Created attachment 1391 [details] gnome-ssh-askpass/contrib Makefile w/ arc4random dependencies Adds arc4random dependencies to gnome-ssh-askpass/contrib Makefile (can't make it work w/o explicitly including vis.o dependency)
What is the treat model that this is intended to defend against. It looks like it is supposed to stop someone who has gained access to my agent socket and can also answer the askpass confirm dialog. Is this correct? BTW all the links at http://www.swcp.com/~pgsery return "forbidden" errors.
(In reply to comment #5) > What is the treat model that this is intended to defend against. It > looks like it is supposed to stop someone who has gained access to my > agent socket and can also answer the askpass confirm dialog. Is this > correct? Yes. It's also designed to protect against a lost or stolen private key by creating a second authentication factor isolated from the ssh client. You first authenticate to the server using your key. The server then e-mails you a random password via an out-of-band channel. You're fully authenticated if you can correctly answer the challenge. > BTW all the links at http://www.swcp.com/~pgsery return "forbidden" > errors. Fixed.
I don't think this explicit support is necessary any more as OpenSSH has gained support for multiple required authentication methods via PAM or BSD authentication that could be used to implement features like this.
closing resolved bugs as of 8.6p1 release