11

Since enabling 2-factor authentication (aka. 2-step verification) on Google, my Google export scripts no longer work. The computer is verified and trusted, but somehow the scripts are not. In effect, every time the cron job is run I receive a new "Google verification code" and the script fails. I assume it should be a simple matter to authenticate such scripts once and for all with wget or curl, but I couldn't find any documentation for how to do it.

Google authentication schemes have gone through many iterations, and I can no longer seem to log in using curl or mechanicalsoup. I've tried using URLs like https://accounts.google.com/ServiceLogin?continue=https://calendar.google.com/calendar/exporticalzip&Email=username@gmail.com&Passwd=application-specific-password, and I always get redirected to a login page, usually with the message "Please use your account password instead of an application-specific password."

l0b0
  • 55,365
  • 30
  • 138
  • 223
  • 2
    You should try using OAuth2 rather than this old deprecated approach, then there is less hassle with the verification tokens. – Tim Apr 23 '12 at 14:22
  • @Tim: Is there a guide for how to use it with shell scripting? – l0b0 Apr 23 '12 at 14:45
  • The spec at http://tools.ietf.org/html/draft-ietf-oauth-v2-25 shows how to do it. I think `curl` might be able to do the https stuff, and let you pass the requests with `--raw`? Or maybe curl has options to fit this kind of thing? – ams Apr 26 '12 at 15:10
  • @ams: Are there any examples or tutorials? – l0b0 Apr 30 '12 at 05:40

4 Answers4

6

Are you absolutely sure that you want to use 2-factor auth with the shell scripts? If so, you don't need to try to get your computer or script as "trusted". You just do the full 2-factor auth every time you run the script.

If the target is to skip the manual second factor auth, I'd suggest using application-specific password instead (as already suggested by other answers). Just pretend that you're not using 2-factor auth at all and use your real login name but set password to one generated at https://accounts.google.com/b/0/IssuedAuthSubTokens?hl=en (subpage of https://www.google.com/settings/security).

The intent is to set Application-specific password "Name" to a value that is meaningful to you. For example, I have passwords labeled "Pidgin at work", "My Android Phone", "Thunderbird Google Address Book Extension at Work" etc. You could have one for "Calendar and Reader Export Script". If you ever believe that this Application-specific password is compromised ("leaked"), just hit the "Revoke" link on the same page and then generate a new password for your script.

For the code, just use the last version that worked with Google single factor auth. Update: because the original question used URL https://accounts.google.com/ServiceLogin for initiating the session login it's practically faking browser login. However, Google does not officially support this and as I'm writing this, it seems that using application specific password for normal login will end up with error message "Please use your account password instead of an application-specific password".

One thing to understand about the Google 2-factor auth and "trusted computer" is that the actual implementation just adds a permanent cookie with 30 days expiry time to your browser. Trusted computer does not mean your IP address were trusted or some other magical connection were created. Unless your scripts capture the "trusted computer" cookie from your browser of choice, it does not matter at all if you've ever marked your computer as trusted. (The Google form should not say "Remember this computer for 30 days" but "Trust this browser and user account combination for 30 days (save permanent cookie)". However, I guess that was considered too technical...)

Update: (copied from my comment below) The only officially supported method (Server to Server applications) is documented at https://developers.google.com/accounts/docs/OAuth2ServiceAccount. It requires OAuth/JWT encoding the request and using Service Account private key created at https://code.google.com/apis/console. As an alternative you could use ClientLogin authentication (already deprecated, best effort service until 2015).

If you decide to go with OAuth, you might want to look at http://blog.yjl.im/2010/05/bash-oauth.html and https://github.com/oxys-net/curl-oauth

Mikko Rantalainen
  • 14,132
  • 10
  • 74
  • 112
  • The error message is "Please use your account password instead of an application-specific password." It seems that google is actively killing any support for using plain password login once 2-factor login is activated. The only officially supported method (Server to Server applications) is documented at https://developers.google.com/accounts/docs/OAuth2ServiceAccount. It requires OAuth/JWT encoding the request and using Service Account private key created at https://code.google.com/apis/console/. As an alternative you could use ClientLogin authentication (best effort service until 2015). – Mikko Rantalainen Jul 10 '12 at 08:15
  • 1
    If you decide to go with OAuth, you might want to look at http://blog.yjl.im/2010/05/bash-oauth.html and https://github.com/oxys-net/curl-oauth – Mikko Rantalainen Jul 10 '12 at 08:36
  • It seems to me that you can only use the `access_token` provided by Google's OAuth2 Service account to access the APIs that Google has publicly available (https://developers.google.com/apis-explorer). meaning you cannot impersonate your own user account and send a request to none API Google endpoints (e.g: https://mail.google.com/mail/u/0/#inbox) just like when you do when you are using the browser. Is that right? – ATheCoder Apr 25 '21 at 12:13
  • This is very old answer but I think that's right. OAuth2 `access_token` is meant to be used with official APIs only. I'd assume that Google doesn't want to support non-official APIs at all and if you *must* impersonate human to do what you want, I guess you have to disable 2 factor authentication to do that. If you proceed with impersonating to use unofficial APIs, be very careful not to trigger any limits or your account could get locked automatically. Google is known to apply all kinds of heuristics for security purposes - non-documented, of course. – Mikko Rantalainen Apr 27 '21 at 14:09
2

My python scripts stopped sending e-mails, so I generated the application specific password, changed my script utility gmail account (e.g., myscriptutility@gmail.com) to that password and then successfully used that password (e.g. 'applicationpassw') through the following python script fragment (sorry, no complete example).

email = SMTPHandler(mailhost=('smtp.gmail.com',587),
    fromaddr='anyaddress@mail.homeserver',
    toaddrs=['whoiwanttomailto@gmail.com'],
    subject= webSite + ' not working',
    credentials=('myscriptutility@gmail.com','applicationpassw'),
    secure=())
logger.addHandler(email)

So it appears, at least with python 3.6.5 on Windows 10, that all one needs to do is change to using the sixteen char application specific password on the account and in the application.

Bruce
  • 121
  • 3
0

Generate an application-specific password. User documentation, developer documentation.

l0b0
  • 55,365
  • 30
  • 138
  • 223
Tgr
  • 27,442
  • 12
  • 81
  • 118
  • I can't figure out how to do it from a shell script. A *lot* of googling has not uncovered a single shell script which seems to be capable of 2-step verification. – l0b0 Apr 25 '12 at 20:34
  • Please check the links - this is a single-step verification using a random-generated password, intended specifically for applications which are incompatible with 2-step verification. – Tgr Apr 25 '12 at 21:50
  • "If you are a Google Apps API developer and use ClientLogin authentication" - I don't, as far as I know - The [authentication script](https://github.com/l0b0/export/blob/master/GoogleAuth.sh) uses `ServiceLoginAuth`, and simply replacing the password with the application-specific password doesn't work. – l0b0 Apr 25 '12 at 22:11
  • I don't know if you can log in that way. You could probably use a one-time code, but that's not very comfortable; or log in via the browser, and use the cookie in the script, but the best way is probably modifying your script to use some other login option ([ClientLogin](https://developers.google.com/accounts/docs/AuthForInstalledApps) is not much different from normal web authentication, though as Tim has noted, it has been deprecated). – Tgr Apr 26 '12 at 14:40
0

Making application specific passwords works for my scripts, all you do is create the password and then in your script where you have your google accounts password enter in the application specific password instead.

See here for more on application specific passwords:

Application Specific Passwords

Hope this helps !!

scrineym
  • 759
  • 1
  • 6
  • 28
  • Tried it already, and it didn't accept the request. Do you have an actual code example? – l0b0 Apr 29 '12 at 17:09