Page MenuHomePhabricator

AWS: Login via SSH key does no longer work
Closed, ResolvedPublicBUG

Description

Hello,

I am deploying VyOS 1.2.x on AWS using the build-ami scripts. In September, SSH login was working perfectly fine. Now, I cannot log in with the SSH key chosen when launching the instance.

Have there been any changes to the login process (I tried various usernames)? I could reproduce this down to 1.2.0-rc5.

Port is open, SSH is responding. Public key authentication is enabled.

Details

Difficulty level
Unknown (require assessment)
Version
1.2.0
Why the issue appeared?
Will be filled on close

Event Timeline

m.tremer created this task.Nov 13 2018, 2:37 PM

Do you also create the iso yourself or dowload it?
In 1.2 we will be using cloud-init and the ec2 init script was removed.

Please try to build the aws iso from vyos-build and use sudo make AWS
instead of sudo make iso.

If you use you own debian jessie build server please update live-build to
debian stretch version (uefi changes) or better yet use Docker.

Op di 13 nov. 2018 15:37 schreef m.tremer (Michael Tremer) <
phabricator@mg.vyos.io>:

Thanks for your reply.

Do you also create the iso yourself or dowload it?
In 1.2 we will be using cloud-init and the ec2 init script was removed.

Yes, I am aware of that I suspect that this is where the problem is.

Please try to build the aws iso from vyos-build and use sudo make AWS
instead of sudo make iso.

I did not build the ISO myself. I used the official RC builds and rolling releases for testing.

oliko added a subscriber: oliko.Nov 15 2018, 10:53 AM

Same problem, but at the bare metal server with VyOS 1.2-rc7 from repo.

In T1003#26043, @oliko wrote:

Same problem, but at the bare metal server with VyOS 1.2-rc7 from repo.

I cannot reproduce this on bare-metal. After setting eth0 to DHCP, enabling SSH and adding a key I could log in with that key via SSH.

This is the configuration I used:

vyos@vyos:~$ show configuration 
interfaces {
    ethernet eth0 {
        address dhcp
    }
    loopback lo {
    }
}
service {
    ssh {
        port 22
    }
}
system {
    config-management {
        commit-revisions 100
    }
    console {
        device ttyS0 {
            speed 9600
        }
    }
    host-name vyos
    login {
        user vyos {
            authentication {
                encrypted-password ****************
                plaintext-password ****************
                public-keys mykey {
                    key ****************
                    type ssh-ed25519
                }
            }
            level admin
        }
    }
    ntp {
        server 0.pool.ntp.org {
        }
        server 1.pool.ntp.org {
        }
        server 2.pool.ntp.org {
        }
    }
    syslog {
        global {
            facility all {
                level info
            }
            facility protocols {
                level debug
            }
        }
    }
}

That's why it either has something to do with the default configuration that build-ami is installing (and where I cannot see anything that doesn't look right) or cloud-init importing something wrong. However, I have no chance to see what configuration is applied by cloud-init (very easily).

syncer triaged this task as Normal priority.

Just to confirm, I tested this with RC8 and unfortunately, it still does not work.

syncer added a subscriber: syncer.Nov 20 2018, 3:00 PM

build-ami is obsolete and never was intended for 1.2 but 1.1
therefore it will not start work and will be removed at some point in favor of aws target

Okay, that is good to know. Unfortunately documentation is heavily outdated. However, I found a fix for this problem which I attached to this message as a patch.

The default vyos user was just missing when an image was being created with "make AWS".

syncer assigned this task to UnicronNL.Nov 21 2018, 7:55 PM
UnicronNL closed this task as Resolved.Nov 23 2018, 9:01 PM

@m.tremer added the patch, thanks... was under the impression cloud-init added the user as it is stated as default user, but clearly it does not.