Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


SolusVM Migration Isssue
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

SolusVM Migration Isssue

serverhoshserverhosh Member, Host Rep
edited October 2018 in Help

Can any one give us the resolve.? This is what we are getting while migrating a KVM VPS from One Node to Another.

==========================================
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 185.63.x.x [185.63.x.x] port 22.
debug1: fd 3 clearing O_NONBLOCK
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /usr/local/solusvm/tmp/4443migrate_private_ssh_key type -1
debug1: identity file /usr/local/solusvm/tmp/4443migrate_private_ssh_key-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-sha1 none
debug1: kex: client->server aes128-ctr hmac-sha1 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<2048<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '185.63.x.x' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
reverse mapping checking getaddrinfo for hosted-by.serverhosh.com [185.63.x.x] failed - POSSIBLE BREAK-IN ATTEMPT!
debug1: Unspecified GSS failure. Minor code may provide more information
Credentials cache file '/tmp/krb5cc_0' not found

debug1: Unspecified GSS failure. Minor code may provide more information
Credentials cache file '/tmp/krb5cc_0' not found

debug1: Next authentication method: publickey
debug1: Trying private key: /usr/local/solusvm/tmp/4443migrate_private_ssh_key
debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: No more authentication methods to try.

Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).

Comments

  • KuJoeKuJoe Member, Host Rep
    edited October 2018

    Try to SSH to the target from the source and troubleshoot from there, it's much easier than using SolusVM for troubleshooting. If you're able to SSH to the target from the source without any errors then open a ticket with SolusVM and have them look at what they broke.

  • AnthonySmithAnthonySmith Member, Patron Provider
    edited October 2018

    can you ssh in to the destination node from the source node?

    I suspect the answer is no but that is the first set in troubleshooting it.

  • serverhoshserverhosh Member, Host Rep

    I can access the Destination Server via SSH from the Source Server properly. Even Other Solusvm node is also working fine while we tried to migrate. Only this Node Causing the Issue.

    Even we tried enabling "GSSAPIAuthentication". but no luck.

  • AnthonySmithAnthonySmith Member, Patron Provider
    edited October 2018

    Just a thought, did you only just install solusvm the destination node, if so it might be at a different version to the source node and that will cause issues with solusvm migrations.

    If it is a fresh install you can get them all on the same version as follows:

    If you are on the stable branch, on the master run: /scripts/upcp 1

    if you are on mainline (you should be), on the master run: /scripts/upcp 2

    If you are on the beta branch on the master run: /scripts/upcp 3

  • serverhoshserverhosh Member, Host Rep

    We have found the Issue luckly and fix. It's a "immutable" flag set on the "authorized_keys file".

    Reference - https://ihazem.wordpress.com/2010/03/31/chown-changing-ownership-of-authorized_keys-operation-not-permitted/

  • So, who handles your ASN?

  • KuJoeKuJoe Member, Host Rep

    @CyberMonday said:
    So, who handles your ASN?

    I'm a bit confused, what does an ASN have to do with this issue? Did SolusVM go in a weird direction that I missed?

  • @KuJoe said:

    @CyberMonday said:
    So, who handles your ASN?

    I'm a bit confused, what does an ASN have to do with this issue? Did SolusVM go in a weird direction that I missed?

    If (!simple_ssh)
       routing(&self) = FALSE;
    
  • KuJoeKuJoe Member, Host Rep

    @CyberMonday said:

    @KuJoe said:

    @CyberMonday said:
    So, who handles your ASN?

    I'm a bit confused, what does an ASN have to do with this issue? Did SolusVM go in a weird direction that I missed?

    If (!simple_ssh)
       routing(&self) = FALSE;
    

    But they aren't related. I know plenty of people who can configure BGP who have never used SolusVM. I know we all look like superheroes but we're all just regular people. ;)

  • @KuJoe said:

    @CyberMonday said:

    @KuJoe said:

    @CyberMonday said:
    So, who handles your ASN?

    I'm a bit confused, what does an ASN have to do with this issue? Did SolusVM go in a weird direction that I missed?

    If (!simple_ssh)
       routing(&self) = FALSE;
    

    But they aren't related. I know plenty of people who can configure BGP who have never used SolusVM. I know we all look like superheroes but we're all just regular people. ;)

    It's just scp tho.

  • doghouchdoghouch Member
    edited October 2018

    @KuJoe said:

    @CyberMonday said:

    @KuJoe said:

    @CyberMonday said:
    So, who handles your ASN?

    I'm a bit confused, what does an ASN have to do with this issue? Did SolusVM go in a weird direction that I missed?

    If (!simple_ssh)
       routing(&self) = FALSE;
    

    But they aren't related. I know plenty of people who can configure BGP who have never used SolusVM. I know we all look like superheroes but we're all just regular people. ;)

    -snipped-

  • ClouviderClouvider Member, Patron Provider
    edited October 2018

    @doghouch said:

    @KuJoe said:

    @CyberMonday said:

    @KuJoe said:

    @CyberMonday said:
    So, who handles your ASN?

    I'm a bit confused, what does an ASN have to do with this issue? Did SolusVM go in a weird direction that I missed?

    If (!simple_ssh)
       routing(&self) = FALSE;
    

    But they aren't related. I know plenty of people who can configure BGP who have never used SolusVM. I know we all look like superheroes but we're all just regular people. ;)

    -snipped-

    >

    Which exchange forgot to filter ;-)?

  • KuJoeKuJoe Member, Host Rep

    @CyberMonday said:

    @KuJoe said:

    @CyberMonday said:

    @KuJoe said:

    @CyberMonday said:
    So, who handles your ASN?

    I'm a bit confused, what does an ASN have to do with this issue? Did SolusVM go in a weird direction that I missed?

    If (!simple_ssh)
       routing(&self) = FALSE;
    

    But they aren't related. I know plenty of people who can configure BGP who have never used SolusVM. I know we all look like superheroes but we're all just regular people. ;)

    It's just scp tho.

    Still unrelated and it's unfair to have such high expectations of people. Not everybody knows everything.

  • doghouchdoghouch Member
    edited October 2018

    @Clouvider -snipped-

Sign In or Register to comment.