gpg: Signature made Sun Jan 3 12:08:40 2016 UTC
gpg: using RSA key 6B6181FDD9EDAC9E
gpg: Can't check signature: No public key
On 03/01/16 11:40, Andy Smith wrote:
> Hi John,
>
> On Sun, Jan 03, 2016 at 10:59:28AM +0000, John Winters wrote:
>> Thanks for the suggestion. Unfortunately, I'm not using ssh-agent so I
>> don't think that's it.
>
> Are you sure? Most people use it without knowing. So you have no
> SSH_AUTH_SOCK environment variable set then?
john@mach2:~$ env | grep SSH
SSH_CLIENT=81.187.217.217 54413 xxx
SSH_TTY=/dev/pts/1
SSH_CONNECTION=81.187.217.217 54413 172.16.1.21 xxx
john@mach2:~$
I type the passphrase for my ssh key each time I connect to my VPS.
>
>> Also, it works fine through the other gateway.
>
> I'm still thinking SSH_AUTH_SOCK because the only time I have ever
> seen what you describe was when that was messed up.
>
> You can rule out most networking issues by doing a tcpdump, and/or
> by running a debug sshd on a different port and scp to that. But as
> ssh works regardless, these aren't going to tell you much.
Yes, that's what's rather baffling me.
The school previously used something called (IIRC) bloxx which sniffed
and interfered with connections - even internal ones. I spent some time
trying to diagnose a failure to fetch debian packages from an internal
caching host. A simple connection worked fine, but fetching a package
(over http) got a REFUSED response, and yet I couldn't find any
corresponding message in the cache server's logs. It turned out that
bloxx was sitting in the middle and monitoring the connection. It let
simple listings through, but when one requested a .deb file it faked the
response.
Trying to do things in schools can be a nightmare, but I don't see how
one could get a similar effect interfering with an ssh connection.
Thanks for the suggestions - I shall keep working at it.
Cheers,
John
