[02:50] <kinghat> my server booted into emergency mode for reasons and when i hit enter it gave me root. is that normal or is that a security issue?
[02:51] <mybalzitch> thats why you don't let untrusted people have console access to your server
[02:51] <mybalzitch> 100% normal on a default install
[02:53] <kinghat> ok just making sure. i didnt know if i should report it or not. thanks for the head up. this is just a basement home server. the only thing that untrusted down there is the sump pump.
[02:53] <sarnold> kinghat: it depends; if you set a root password, you'll be prompted for it. if you didn't set a root password, you won't be prompted for it.
[02:54] <sarnold> kinghat: anyone at the console can simple add "init=/bin/bash" or "init=/usr/bin/bash" and get instaroot without prompting anyway
[02:55] <kinghat> nah i only set the user account password when i install iirc. i did set passwordless login for ssh though 😁
[02:56] <sarnold> hopefully thats passwordless because you use keys, and not passwordless because it's now even worse than telnet :)
[02:56] <kinghat> ya because im using keys
[02:57] <kinghat> so the only way to not give root at the console is to set a password for root?
[03:00] <sarnold> I think it's a bunch of steps: (a) set the master and operator passwords on your bios (b) use secure boot on the bios (c) lock the bios to booting just grub (d) set a password on grub to prevent changing the command line (e) use a full-disk encryption system to make sure the drive can't be used without supplying a decryption key
[03:01] <kinghat> oh ya duh. if they are at the console they can probably just take the drive if they wanted.
[03:04] <kinghat> thanks for the schooling 🙏
[10:06] <icey> jamespage: would you be available to review https://code.launchpad.net/~chris.macnaughton/ubuntu/+source/openvswitch/+git/openvswitch/+merge/387852 ?
[11:24] <jamespage> icey: merged
[11:24] <jamespage> doing 2.13.1 alongside that so will upload later
[11:25] <icey> :-D
[14:12] <Delemas> I realize this is an archaeology question at this point but I'm trying to figure out why an openssh 7.2p2 server, despite being able to generate them, refuses to understand newer hostkey formats ex. ed25519 and ecdsa. Anyone know why?
[14:12] <Delemas> This is on 16.04
[14:14] <sdeziel> Delemas: got some logs and sshd_config to share ?
[14:15] <sdeziel> 16.04 isn't yet in the archaeology realm ... had you said 8.04 maybe ;)
[14:24] <Delemas> sdeziel, basically I'm trying to figure out what 16.04 based openssh-server 1:7.2p2-4ubuntu2.10 is giving this is in ssh -v connection to it: debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
[14:25] <Delemas> other than setting the hostkeys there isn't anything in the configuration which should be restricted that.
[14:25] <Delemas> restricting that...
[14:26] <Delemas> ugh language skills may be broken today... lol
[14:35] <sdeziel> Delemas: please share the sshd_config
[15:52] <rangergord> if I'm setting up multiple systems by cloning a working Ubuntu Server disk then writing that disk image to another system, are there anythings in particular I should modify to avoid issues from having these machines on the same LAN? I know about /etc/hostname (which isn't an issue) and IP conflicts, what other concerns are there?
[15:56] <sdeziel> rangergord: you'll want to "rm -f /etc/ssh/ssh_host_*key*" at least
[15:56] <sdeziel> IIRC, those are created on demand if missing
[15:58] <sdeziel> hmm, they are not created on demand with Bionic, so add "ssh-keygen -A" to your first run script
[16:10] <rangergord> Allright, thanks