I'm trying to access a DigitalOcean droplet through FileZilla. I created a keypair using 'ssh-keygen' and provided DigitalOcean with the public key. When I open FileZilla -> Edit -> Settings -> SFTP, I click 'Add key file...' and select my private key (starting '-----BEGIN OPENSSH PRIVATE KEY-----'). I then get a popup telling me the format isn't supported and asks me if i'd like to convert the file, to which I say yes and enter the password for the file which validates. I provide a new filename in the same directory and click save, which give me the 'Could not get reply from fzputtgen' error message.
I've tried re-downloading and installing FileZilla with no success but really have no idea where to go as the error is so vague. Hopefully somebody here has experience with this issue and can shed some light as to how I might go about fixing it. I'm sure I could create a keypair using PuTTY and skip this step, but it would be nice to have an explanation for why this is failing.
It seems 3.55 has the issue but works OK on 3.56.2.
Please refer to answer dated 27 Sep 2021 here: https://forum.filezilla-project.org/viewtopic.php?t=54091
It seems that the error "Could not get reply from fzputtygen" while import RSA key generated using ssh-keygen is a new bug in Mac computers, as reported at https://trac.filezilla-project.org/ticket/12494#no1.
For this specific issue, keep track (at above url) until this still open case gets solved.
I'm trying to create a custom authentication method for Google cloud endpoints. The idea being I can configure my ESPv2 container (an Extensible service proxy based on Envoy), which is hosted on Google cloud run, to obtain JWT's from a custom issuer, also hosted on cloud run.
Following the guide Endpoints guide for gRPC, I figure the jwks_uri: part of the yaml file should point to a URL which exposes the public key (which I figure you can do by putting a JWK into a json file and hosting said JSON file on google cloud storage, exposing it to the public internet).
The part that has me stumped is the issuer, I've gone through RFC7519, which states that the issuer is a string or URI value. I'm not very familiar with the specific implementation of Envoy that the ESPv2 container uses, but my best guess is the issuer: option in the yaml file is simply used to match against the domain or string that was issued from the server when the token was created.
I'm probably wrong so I'd really appreciate some guidance on this one.
Kind regards,
Despicable B
issuer should be the "iss" field in the JWT token that you send to ESPv2.
Author's Solution
After working with the Google Cloud endpoints team, and some of the contributors for ESPv2, we figured it out (as well as found a few things to point out to anyone wanting to do this in future).
Addressing the original question
Indeed as Wayne Zhang pointed out, the issuer can be ANY string value so long as it matches the "iss" claim in the JWT payload.
e.g.
authentication:
providers:
- id: some-fancy-id
issuer: fart # <-- Don't wrapping ANY these in double-quotes
jwks_uri: https://storage.googleapis.com/your-public-bucket/jwk-public-key.json
audiences: some-specific-name
and then in your (decoded) JWT
// Header
{
"alg": "RS256",
"kid": "custom-id-system-you-specify",
"typ": "JWT"
}
// Payload
{
"aud": [
"some-specific-name"
],
"exp": 1590139950, <-- MUST be INTEGER value
"iat": 1590136350, <-- ^^
"iss": "fart",
"sub": "Here is some sulphur dioxide"
}
Error/Bug #1 - "iat" and "exp" should be an integer NOT a string
As you can already see from the above decoded JWT, the "exp" and "iat" claims MUST be integer values (this can be seen clearly in the RFC7519 section 4.1.4 and 4.1.6).
This seems like a simple mistake, but as the ESPv2 contributors and I found, the error messages weren't particularly helpful at helping the developer figure out what the problem was.
For example, if you had written the "iat" and "exp" claims as strings rather than integers, the ESPv2 container would inform the dev that his JWT was either not proper Base64URL formatted or was invalid JSON. Which, to the unaware, might seem like you've used the library incorrectly.
Some changes to the error messages were made to address this in future, you can see the issue that was raised, and its conclusion here.
Error #2 - Wrong key, and JSON format
Before claiming victory over this battle of attrition, I ran into one more error which was just about as vague as the previous.
When trying to call a method that required authentication, I was greeted with the following
grpc._channel._InactiveRpcError: <_InactiveRpcError of RPC that terminated with:
status = StatusCode.UNAUTHENTICATED
details = "Jwks remote fetch is failed"
debug_error_string = "{"created":"#1590054504.221608572","description":"Error received from peer ipv4:216.239.36.53:443","file":"src/core/lib/surface/call.cc","file_line":1056,"grpc_message":"Jwks remote fetch is failed","grpc_status":16}"
>
Which you might think means that the ESPv2 couldn't retrieve your key.
The cause was three related issues.
ESPv2 only supports X509 and RSA key pairs, so don't make the same mistake I did and use EC generated key pairs.
jwcrypto does NOT add the "alg" and "kid" claims to your key file by default, make sure these are added or jwcrypto won't know what algorithm to use when signing any JWTs you've generated.
The final error was the format of the JSON file. When you call the methods to export the keys, you get the following:
{
"e":"XXXX",
"kty":"RSA",
"n":"crazyRandomNumbersAndLetters",
"alg": "RS256", <-- NOT ADDED BY DEFAULT
"kid": "custom-id-system-you-specify" <-- ^^
}
Simply providing a URL to this in a JSON file is incorrect. The proper format is as follows:
{
"keys": [
{
"e":"XXXX",
"kty":"RSA",
"n":"crazyRandomNumbersAndLetters",
"alg": "RS256", <-- NOT ADDED BY DEFAULT
"kid": "custom-id-system-you-specify" <-- ^^
}
]
}
If you do all this, it should be smooth sailing.
I apologise for getting a little off topic, but I hope others don't have to jump through as many hoops as I did to get this going :)
I can't thank the developers at ESPv2 enough for their quick replies and insight into the problem. Top job!
Best of luck coding!
Despicable B.
In Postman, I did these: Import > Import From Link, and then I entered a URL
https://www.getpostman.com/collections/1c6c3d5cfe3b12978a5f
And then I hit "Import". But then nothing happened. There were no error messages. The click simply gave no response/action from the UI.
Did I miss something?
( The above procedures and link were suggested from this blog article from Postman offical site)
I was using Postman v6.6.1
If you use Postman to hit the same URL you'll see this:
Error: Collection not found.
It's probably a deleted collection.
Checking the logs, I can see that there's an error that the resource couldn't be found but yeah the UI apparently doesn't give you any feedback regarding this which can be reported.
You can report the issue on the public issue tracker
Import worked after restarting the postman ,
version : Version 7.6.0 (7.6.0)
I wrote a program to simply just read the unofficial binary list from "https://www.lfd.uci.edu/~gohlke/pythonlibs/" and then use beautifulSoup to just produce a table of all packages in the webpage but I keep getting this error
Requests giving EOF occurred in violation of protocol (_ssl.c:661)
Here is my code also I am using a windows machine with Python 2.7.14:
import urllib2
from bs4 import BeautifulSoup
url = urllib2.urlopen("https://www.lfd.uci.edu/~gohlke/pythonlibs/").read()
print(url)
I could not find any reference to (_ssl.c:661) after looking around, any and all suggestions would be highly appreciated.
i came accross the following error, when my client tries to edit list data through datasheet view from terminal machine.
The Web application at xxx could not be found. Verify that you have typed the URL
correctly. If the URL should be serving existing content, the system administrator may
need to add a new request URL mapping to the intended application.
Note: this error is coming with only 1 list. All other lists are working fine. i m using sharepoint 2007 on 32bit
This may be related to alternate access mappings.
I had this issue, and the clue was that the datasheet was referencing a URL of the form:
_http://hostname/site/...
instead of
_http://hostname.domain/site/...
ie. the datasheet was not referencing the fully qualified domain name (FQDN).
If the error message states The Web application at _http://hostname/site/..., ie. the error doesn't use the FQDN, alternate access mapping may resolve it. The end of the error message seems to suggest alternate access mappings, although it is not entirely explicit.
I resolved this by adding an alternate access mapping as follows:
internal url: http://hostname
public url: http://hostname.domain (FQDN)
Default Zone in my case, should work for other zones.
hope this helps :)