Bristol and Bath Linux: Bristol Digest, Vol 676, Issue 3

Send Bristol mailing list submissions to
bristol@mailman.lug.org.uk

To subscribe or unsubscribe via the World Wide Web, visit
https://mailman.lug.org.uk/mailman/listinfo/bristol
or, via email, send a message with subject or body 'help' to
bristol-request@mailman.lug.org.uk

You can reach the person managing the list at
bristol-owner@mailman.lug.org.uk

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Bristol digest..."

Today's Topics:

1. ssh to Google Cloud problem (Martin Moore)
2. Re: ssh to Google Cloud problem (Amias Channer)
3. Re: Unable VNC into a Rpi Desktop (Peter Hemmings)
4. Re: ssh to Google Cloud problem (Martin Moore)

----------------------------------------------------------------------

Message: 1
Date: Tue, 03 Jan 2017 14:02:41 +0000
From: Martin Moore <martinm@it-helps.co.uk>
To: Bristol and Bath Linux User Group <bristol@mailman.lug.org.uk>
Subject: [bristol] ssh to Google Cloud problem
Message-ID: <02C7F1B5-D0CF-4232-9393-0921667114DE@it-helps.co.uk>
Content-Type: text/plain; charset="UTF-8"

I'm having problems getting backuppc to work on Google Cloud.

One possible issue is that I can't ssh as root to the GC instance. I CAN ssh as a user other than root.

Any pointers?

Ta.

root@NewDev:~/.ssh# ssh -v gcinstance
OpenSSH_6.5, OpenSSL 1.0.1k 8 Jan 2015
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to gcbackup [xx.xx.xx.xx] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/id_rsa type 1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.5p1 Debian-4
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7p1 Debian-5+deb8u3
debug1: match: OpenSSH_6.7p1 Debian-5+deb8u3 pat OpenSSH* compat 0x04000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-sha1-etm@openssh.com none
debug1: kex: client->server aes128-ctr hmac-sha1-etm@openssh.com none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 11:9f:25:4f:c1:xx:42:b1:xx:03:d8:94:8f:f8:58:01
debug1: Host 'gcbackup' is known and matches the ECDSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /root/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Trying private key: /root/.ssh/id_ecdsa
debug1: Trying private key: /root/.ssh/id_ed25519
debug1: No more authentication methods to try.
Permission denied (publickey).

------------------------------

Message: 2
Date: Tue, 3 Jan 2017 14:33:53 +0000
From: Amias Channer <me@amias.net>
To: Bristol and Bath Group <bristol@mailman.lug.org.uk>, Martin Moore
<martinm@it-helps.co.uk>
Subject: Re: [bristol] ssh to Google Cloud problem
Message-ID:
<CAMgU7XXS3EzryGPcc5D_=cSUw=H89DM7vfn3j3V4uzKnTM_Dxw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hello Martin,

Ssh roaming is now deprecated due to security issues, its the magic
reconnect thing that ssh does and it's been abused.

Tldr: disable the roaming options in your ssh client config.

For more info
http://superuser.com/questions/825634/what-could-roaming-not-allowed-by-server-of-ssh-client-mean

Cheers
Amias

On 3 Jan 2017 2:03 p.m., "Martin Moore via Bristol" <
bristol@mailman.lug.org.uk> wrote:

I'm having problems getting backuppc to work on Google Cloud.

One possible issue is that I can't ssh as root to the GC instance. I CAN
ssh as a user other than root.

Any pointers?

Ta.

root@NewDev:~/.ssh# ssh -v gcinstance
OpenSSH_6.5, OpenSSL 1.0.1k 8 Jan 2015
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to gcbackup [xx.xx.xx.xx] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/id_rsa type 1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.5p1 Debian-4
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7p1
Debian-5+deb8u3
debug1: match: OpenSSH_6.7p1 Debian-5+deb8u3 pat OpenSSH* compat 0x04000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-sha1-etm@openssh.com none
debug1: kex: client->server aes128-ctr hmac-sha1-etm@openssh.com none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 11:9f:25:4f:c1:xx:42:b1:xx:03:
d8:94:8f:f8:58:01
debug1: Host 'gcbackup' is known and matches the ECDSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /root/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Trying private key: /root/.ssh/id_ecdsa
debug1: Trying private key: /root/.ssh/id_ed25519
debug1: No more authentication methods to try.
Permission denied (publickey).

_______________________________________________
Bristol mailing list
Bristol@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/bristol
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.lug.org.uk/mailman/private/bristol/attachments/20170103/cde81ee1/attachment-0001.html>

------------------------------

Message: 3
Date: Tue, 3 Jan 2017 15:17:37 +0000
From: Peter Hemmings <peternsomerset@virginmedia.com>
To: bristol@mailman.lug.org.uk
Subject: Re: [bristol] Unable VNC into a Rpi Desktop
Message-ID: <a0e96508-1060-8a45-7c2e-45bba4ee76e0@virginmedia.com>
Content-Type: text/plain; charset=utf-8; format=flowed

Update,

On 03/01/17 11:43, Dave Addison via Bristol wrote:
> Quoting Peter Hemmings via Bristol <bristol@mailman.lug.org.uk>:
>
>> On 02/01/17 18:25, Sebastian via Bristol wrote:
>>> Also you can only use one graphical one at once as far as I know,
>>> can't use more than one I belive.
>>
>> OK, if that's so I will stop/remove the rdp server before
>> reverting to a new install which is a bit of a "cop out"!

I have a fresh Raspian on the pi.

First the good news, I can open the desktop on my Android Vnc Viewer
after enabling the service on the pi config (which was greyed out on old
install due to my tinkering!)
I checked this connection as being 192.168.0.15:5900.

Now the bad news, using "Remote Desktop Viewer" in Fedora 25 it reports
"Connection to host closed".

So I assume its either a firewall config problem or viewer problem.

At least the pi now works and has a server running!

>>
>> -- Peter H
> Hi
>
> There's nothing stopping you from running multiple X displays on the
> same machine but they must have a different display number. The
> display number defines the unix sockets and network ports that the
> display software will try and use for connections from clients.

>
> It's possible that vnc is attempting to set up using the same display
> number as the rdp server in which case it will fail repeatedly as
> you're seeing in the systemd output.

Yep I think that could have been the problem as I do not remember
setting the number!

It should be logging to either
> the system journal or a log file somewhere and this should provide a
> more helpful error message
>
> ssh can be used to forward graphical clients. ssh -X user@hostname
> will provide an encrypted connection back to the X display on your
> local machine. I use the quite a lot with the pi as it offloads the
> running of the X-display software.
>
> Regards Dave
>
>
>
> _______________________________________________ Bristol mailing list
> Bristol@mailman.lug.org.uk
> https://mailman.lug.org.uk/mailman/listinfo/bristol
>

Regards

--
Peter H

------------------------------

Message: 4
Date: Tue, 03 Jan 2017 15:49:30 +0000
From: Martin Moore <martinm@it-helps.co.uk>
To: Amias Channer <me@amias.net>, Bristol and Bath Linux User Group
<bristol@mailman.lug.org.uk>
Subject: Re: [bristol] ssh to Google Cloud problem
Message-ID: <A677054C-D6C2-4756-A513-973D1C09D1AB@it-helps.co.uk>
Content-Type: text/plain; charset="utf-8"

Thanks Amias, AFAIK I'm not roaming.

The backuppc error is

Fetching remote protocol

Got remote protocol 1953722184

Fatal error (bad version): Host key verification failed.

But googling shows that this probably means the far end (non-google server) is outputting some text not expected.

I've run the cmd that backuppc is trying from gcinstance to my server. It looks like it's running on my server, but isn't sending files back, also has 0s cpu time.

gcinstance$ /usr/bin/ssh -x -v -l root myserver.com /usr/bin/rsync --server --sender --numeric-ids --perms --owner --group -D --links --hard-links --times --block-size=2048 --recursive -D --ignore-times . /home/

OpenSSH_6.7p1 Debian-5+deb8u3, OpenSSL 1.0.1t 3 May 2016

debug1: Reading configuration data /etc/ssh/ssh_config

debug1: /etc/ssh/ssh_config line 19: Applying options for *

debug1: Connecting to myserver.com [xx.xx.xx] port 22.

debug1: Connection established.

debug1: identity file /home/martinm/.ssh/id_rsa type 1