'core' default password is not documented.

[bartonski]

In docs/using-coreos/index.md the default user is shown to be core

NOTE: the user for ssh is core.

When I try to log in via ssh, I am prompted for a password -- the default password is neither empty nor core -- the obvious choices. What is the default password?

[philips]

@bartonski There is no default password. You need to use ssh key auth. On vagrant you can use vagrant ssh, on ec2 you can use the key pair, on qemu you can use the scripts we provide http://coreos.com/docs/qemu/#ssh-keys

[jasonk000]

This assumes the network comes up cleanly, which if it doesn't, how does one log in to the host?

[polvi]

Which environment are you trying to boot with?

[jasonk000]

Production environment; see here - https://groups.google.com/forum/#!topic/coreos-dev/Ynm9URNTM74

[kunthar]

@jasonk000 +1

[marineam]

Yeah, sorry about the bnx2 driver being broken. I'm half way through fixing the firmware situation in our builds so the next release should fix that. The ability to set a password for the 'core' user is also in progress but that is part of a larger restructuring of the whole filesystem. That should land this month though.

[philips]

@marineam Most of the trouble with the core password is on real hardware where network doesn't come up. I was thinking of adding an 'no_passwd' parameter to the kernel that would remove the login from the getty.

[marineam]

@philips or a 'setup' option that replaces getty on tty1 (or setup=ttyS0 for others) that prompts the user to set a password and maybe optionally asks for other things like hostname or timezone. Those things people expect from a normal installer. :) After the usr switch I also intend to add password setup to the install script.

Caffeinated and will be hacking like crazy today, seriously need to get this filesystem fixed.

[Telmo]

any updates on this? In my vCenter the CoreOS image wont come up with an IP so I can't login to it.

[robszumski]

@Telmo We're really close to finishing up new images that support cloud-config. With those images you'll be able to create and modify users, including the core user: https://github.com/coreos/coreos-cloudinit/blob/master/Documentation/cloud-config.md#users Stay tuned.

[marineam]

For the record in case someone is following along, there is a coreos.autologin kernel option to enable passwordless login on a console and config-drive is supported on all VM platforms. I'd generally recommend using config-drive if you don't have any other way to install a cloud config rather than dealing with kernel options.

kernel options documented here: http://coreos.com/docs/running-coreos/bare-metal/booting-with-pxe/ config drive: https://github.com/coreos/coreos-cloudinit/blob/master/Documentation/config-drive.md

[seemsindie]

I have no idea what to do. To confusing for me :)

I followed the vagrant setup guide, and i did all the steps and all went ok. But the last one is displaying this when i try to ssh to it:

λ vagrant ssh core-01 -- -A                                              
Enter passphrase for key 'C:/Users/Ivan/.vagrant.d/insecure_private_key':
core@127.0.0.1's password:                                               
core@127.0.0.1's password:                                               
core@127.0.0.1's password:                                               
Permission denied (publickey,password,keyboard-interactive).

for ssh passphrase i just press enter and it asks me fore core password. Shouldn't this be passwordless login?

[crawford]

@peacemaker94 I'm guessing you have a password on your private key. When you hit enter instead of entering your password, it fails to authenticate with the key and falls back to password authentication (which, of course, will fail).

[seemsindie]

@crawford Well that is weird, cuz i don't remember choosing any passphrase for that key...

[crawford]

@peacemaker94 actually, now that I look at it again, you're using the vagrant-provided key (which won't have a password). Its likely that there is an issue with your cloud-config.

Rather than hijacking this thread, open up a new issue and I'll follow up with you there (or hop on #coreos on freenode).

[mingderwang]

don't use root to ssh, use "core" user account without password prompt, such as $ssh -i xxx.pem core@54.64.18.203

[Telmo]

@mingderwang if the network doesn't come up and you have to login via the console you can't pass an ssh key to authenticate the session.

[crawford]

If you are logging in via the console, you can use the autologin boot arg to disable the password check (boot_kernel coreos.autologin at the boot prompt).

[kelvinhammond]

Doesn't work. I'm guessing that for some reason the cloud-config.yml isn't being read. I verified the yaml file with yamllint so its not the yaml file. I've tried stable, beta, and alpha releases.

I noticed from the console that the hostname isn't set which leads me to believe the cloud-config isn't working.

I'm guessing you didn't add a default password because of automated deployments. You should add a default password if the yaml file fails. Right now, there is no way to log into the box at all even with physical access to the machine, you need a better solution.

I'm using Xen PV w/ pygrub to boot the installed coreos and am unable to login because of this issue. I've used a Xen HVM to install coreos but when rebooting into the Xen HVM it reboots on boot. The Xen PV with pygrub doesn't do that, I just can't login though.

cloud-config.yaml used ssh keys but the keys don't work, it ask for a password. The password isn't the one for the key, ssh would have asked specifically for the key password if that were the case.

[philips]

@kelvinhammond Can you post your cloud config so we can take a look? How are you getting the cloud-config into the system? Do you know if the machine has networking?

[rAy82]

Hello, I've experiencing a similar problem: I cannot login in coreos because when I try to establish a ssh session, the system replies:

ssh -i insecure_ssh_key core@192.168.1.104 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Permissions 0644 for 'insecure_ssh_key' are too open. It is recommended that your private key files are NOT accessible by others. This private key will be ignored. bad permissions: ignore key: insecure_ssh_key Enter passphrase for key 'insecure_ssh_key':

...and naturally I've no passphrase to enter. Addtional infos: I'm trying to run the coreos for the first time using the .zip package and the ssh key contained in it; I'm running coreos vmx file on VMware Workstation installed on a Win7 OS. Any help would be appreciated

[philips]

@rAy82 Where did you get insecure_ssh_key? Can you be more clear on the steps you took?

/cc @marineam

[marineam]

It is included in the vmware_insecure zip file with the image. The prompting for a passphrase is odd, likely a bug in your ssh client, because the line above is where the actual error is. The key is ignored because it is globally readable, run chmod 0600 on the key file or whatever the windows equivalent is. After that it should work.

[rAy82]

thank you for the hint... I'm going to try changing the permission level. I'll reply as soon as I do it

[rAy82]

hello again, I actually had no success in finding a way to make chmod command work in Windows. chmod is available in windows and it seems to work but it doesn't, because when I try again to ssh to my coreos vm I've the same message. So I installed a debian VM and operated the change from 0644 to 0600 from that machine. Of course now it works and at last I succeeded connecting to the coreos machine. Thank you guys for your help!

[ctavernier]

Hello,

I tried to install coreos from an iso, it works well except that when I reboot, I have no login and password? I have no idea how to fix this during the installation steps?

[webmutation]

Trying to install this on a Proxmox VE 3.3 setup, I have no way to place a ssh key since the installation is just a CoreOS iso how can I su? I only ask because I try to run docker and its returning "Cannot connect to the Docker daemon" error, if I try to start with Docker -d it tells me i dont have permissions, if I try to su it teels me crypt: Invalid argument. Kind of stuck right now.

[robszumski]

If you're already booted into the ISO, it probably makes the most sense to install to disk and provide a cloud-config that has an SSH key specified.

The core user should be in the sudoers group by default. If you wanted to set a password or create another user, you can do this via cloud-config.

[webmutation]

@robszumski I will try to do that... The OS is running inside a Proxmox VM I need to find a way to install to disk to that VM with a cloud-config.

[langdead]

My coreos was installed var vagrant last week, with kenel 3.17.8, the latest version so far. vagrant box add coreos http://stable.release.core-os.net/amd64-usr/current/coreos_production_vagrant.box I still get the problem that both system login and vagrant ssh need a password.

Before the failure this time, I did succeed var vagrant ssh two days ago.

Now what can I do, please? Reinstall the coreos? Help is appreciated!

[robszumski]

@langdead Have you made any changes to the coreos-vagrant repo since you pulled it down?

[langdead]

@robszumski Thanks for contacting! If I remember correctly, no. I even didn't find where the repo locates in my disk. :(. I just tried installing redmine during the last successful login.

To check what happens behind, I re-initiated the coreos by. 1 vagrant destroy 2 vagrant init coreos 3 changing the ip configuration and enable virtualbox gui in the file "Vagrant" 3 vagrant up

The first time it boots correctly, and vagrant ssh works. Then either in ssh shutdown -h 0 or vagrant halt from the host shell.

Now in host shell, vagrant up fails to login.

Following is the shell output. Don't know whether there are some hint for you. Thanks for your help in advance!

//--------------------------succeeded output----------------- langdead@fuple:~/work/fuple-vm$ vagrant up /opt/vagrant/bin/../embedded/gems/gems/vagrant-1.7.2/lib/vagrant/pre-rubygems.rb:31: warning: Insecure world writable dir /opt/Qt5.0.2/Tools in PATH, mode 040777 /opt/vagrant/embedded/gems/gems/bundler-1.7.11/lib/bundler/runtime.rb:222: warning: Insecure world writable dir /opt/Qt5.0.2/Tools in PATH, mode 040777 Bringing machine 'default' up with 'virtualbox' provider... ==> default: Importing base box 'coreos'... ==> default: Matching MAC address for NAT networking... ==> default: Setting the name of the VM: fuple-vm_default_1423146481080_9299 ==> default: Clearing any previously set network interfaces... ==> default: Preparing network interfaces based on configuration... default: Adapter 1: nat default: Adapter 2: hostonly ==> default: Forwarding ports... default: 80 => 10080 (adapter 1) default: 22 => 2222 (adapter 1) ==> default: Running 'pre-boot' VM customizations... ==> default: Booting VM... ==> default: Waiting for machine to boot. This may take a few minutes... default: SSH address: 127.0.0.1:2222 default: SSH username: core default: SSH auth method: private key default: Warning: Connection timeout. Retrying... default: default: Vagrant insecure key detected. Vagrant will automatically replace default: this with a newly generated keypair for better security. default: default: Inserting generated public key within guest... default: Removing insecure key from the guest if its present... default: Key inserted! Disconnecting and reconnecting using new SSH key... ==> default: Machine booted and ready! ==> default: Configuring and enabling network interfaces... langdead@fuple:~/work/fuple-vm$ vagrant ssh /opt/vagrant/bin/../embedded/gems/gems/vagrant-1.7.2/lib/vagrant/pre-rubygems.rb:31: warning: Insecure world writable dir /opt/Qt5.0.2/Tools in PATH, mode 040777 /opt/vagrant/embedded/gems/gems/bundler-1.7.11/lib/bundler/runtime.rb:222: warning: Insecure world writable dir /opt/Qt5.0.2/Tools in PATH, mode 040777 CoreOS (stable) core@localhost ~ $ exit logout Connection to 127.0.0.1 closed.

//----------------------------------failed output---------------------- langdead@fuple:~/work/fuple-vm$ vagrant halt /opt/vagrant/bin/../embedded/gems/gems/vagrant-1.7.2/lib/vagrant/pre-rubygems.rb:31: warning: Insecure world writable dir /opt/Qt5.0.2/Tools in PATH, mode 040777 /opt/vagrant/embedded/gems/gems/bundler-1.7.11/lib/bundler/runtime.rb:222: warning: Insecure world writable dir /opt/Qt5.0.2/Tools in PATH, mode 040777 ==> default: Attempting graceful shutdown of VM... langdead@fuple:~/work/fuple-vm$ vagrant up /opt/vagrant/bin/../embedded/gems/gems/vagrant-1.7.2/lib/vagrant/pre-rubygems.rb:31: warning: Insecure world writable dir /opt/Qt5.0.2/Tools in PATH, mode 040777 /opt/vagrant/embedded/gems/gems/bundler-1.7.11/lib/bundler/runtime.rb:222: warning: Insecure world writable dir /opt/Qt5.0.2/Tools in PATH, mode 040777 Bringing machine 'default' up with 'virtualbox' provider... ==> default: Clearing any previously set forwarded ports... ==> default: Clearing any previously set network interfaces... ==> default: Preparing network interfaces based on configuration... default: Adapter 1: nat default: Adapter 2: hostonly ==> default: Forwarding ports... default: 80 => 10080 (adapter 1) default: 22 => 2222 (adapter 1) ==> default: Running 'pre-boot' VM customizations... ==> default: Booting VM... ==> default: Waiting for machine to boot. This may take a few minutes... default: SSH address: 127.0.0.1:2222 default: SSH username: core default: SSH auth method: private key default: Warning: Connection timeout. Retrying... default: Warning: Authentication failure. Retrying... .................................. default: Warning: Authentication failure. Retrying... Timed out while waiting for the machine to boot. This means that Vagrant was unable to communicate with the guest machine within the configured ("config.vm.boot_timeout" value) time period. ............................................ If the box appears to be booting properly, you may want to increase the timeout ("config.vm.boot_timeout") value. langdead@fuple:~/work/fuple-vm$ vagrant ssh /opt/vagrant/bin/../embedded/gems/gems/vagrant-1.7.2/lib/vagrant/pre-rubygems.rb:31: warning: Insecure world writable dir /opt/Qt5.0.2/Tools in PATH, mode 040777 /opt/vagrant/embedded/gems/gems/bundler-1.7.11/lib/bundler/runtime.rb:222: warning: Insecure world writable dir /opt/Qt5.0.2/Tools in PATH, mode 040777 core@127.0.0.1's password: core@127.0.0.1's password:

[robszumski]

default: Vagrant insecure key detected. Vagrant will automatically replace default: this with a newly generated keypair for better security. default: default: Inserting generated public key within guest... default: Removing insecure key from the guest if its present... default: Key inserted! Disconnecting and reconnecting using new SSH key...

It seems like Vagrant has generated new keys for that CoreOS machine. I wasn't aware that this feature existed, I think it's new. If you set config.ssh.insert_key = false, that should disable the feature.

It seems like this is already in coreos-vagrant, you might have an old copy on your machine.

[langdead]

@robszumski, thanks very much! Adding config.ssh.insert_key = false fixed the issue!

I meant to try coreos-vagrant, but the great GFW of China blocked... And, annoyingly, seemed that coreos-net is also blocked since this week...

Anyway, I can play with kernel 3.17.8 for some time... :)