32

Just updated to 20.04 final release, and I'm seeing these messages in /var/log/auth.log...

May 14 06:29:52 Satellite-E55 gdm-password]: pam_unix(gdm-password:auth): Couldn't open /etc/securetty: No such file or directory
May 14 07:40:14 Satellite-E55 su: pam_unix(su:auth): Couldn't open /etc/securetty: No such file or directory

I looked back at a 19.10 VM, and /etc/securetty was there. All my 20.04 systems are missing this file. Two 20.04 installations are upgrades, and one installation is a fresh install VM.

What's up with this file missing in 20.04? Should I restore a copy from 19.10?

Update #1:

The same problem occurs in 20.10, in both upgrades and fresh installs.

5
15

There is an example file that you can copy.

sudo cp /usr/share/doc/util-linux/examples/securetty /etc/securetty
3
  • I don't think this answer really answers the question. Try to be more specific. – SyntheticHuman Dec 3 '20 at 2:18
  • 9
    I prefer this solution over the one in the accepted answer as it copies a file that is already on your system and has less entries hence specifying fewer ttys to be secure hence being a more restrictive option. – Martin Rüegg Jan 16 at 9:48
  • This path may be missing on a minified system (docker?) where dpkg is set to exclude /usr/share/doc/* – Jeremy L Jun 12 at 20:00
14

Here's a copy of /etc/securetty from a 19.10 desktop installation. Only tested for a couple of minutes, but so far /var/log/auth.log is quiet.

When placed into /etc the file should look like this:

-rw-r--r-- 1 root root 4.1K May 14 10:31 securetty

Here are the /etc/securetty contents:

# /etc/securetty: list of terminals on which root is allowed to login.
# See securetty(5) and login(1).

console

# Local X displays (allows empty passwords with pam_unix's nullok_secure)
:0
:0.0
:0.1
:1
:1.0
:1.1
:2
:2.0
:2.1
:3
:3.0
:3.1
#...


# ==========================================================
#
# TTYs sorted by major number according to Documentation/devices.txt
#
# ==========================================================

# Virtual consoles
tty1
tty2
tty3
tty4
tty5
tty6
tty7
tty8
tty9
tty10
tty11
tty12
tty13
tty14
tty15
tty16
tty17
tty18
tty19
tty20
tty21
tty22
tty23
tty24
tty25
tty26
tty27
tty28
tty29
tty30
tty31
tty32
tty33
tty34
tty35
tty36
tty37
tty38
tty39
tty40
tty41
tty42
tty43
tty44
tty45
tty46
tty47
tty48
tty49
tty50
tty51
tty52
tty53
tty54
tty55
tty56
tty57
tty58
tty59
tty60
tty61
tty62
tty63

# UART serial ports
ttyS0
ttyS1
ttyS2
ttyS3
ttyS4
ttyS5
#...ttyS191

# Serial Mux devices    (Linux/PA-RISC only)
ttyB0
ttyB1
#...

# Chase serial card
ttyH0
ttyH1
#...

# Cyclades serial cards
ttyC0
ttyC1
#...ttyC31

# Digiboard serial cards
ttyD0
ttyD1
#...

# Stallion serial cards
ttyE0
ttyE1
#...ttyE255

# Specialix serial cards
ttyX0
ttyX1
#...

# Comtrol Rocketport serial cards
ttyR0
ttyR1
#...

# SDL RISCom serial cards
ttyL0
ttyL1
#...

# Hayes ESP serial card
ttyP0
ttyP1
#...

# Computone IntelliPort II serial card
ttyF0
ttyF1
#...ttyF255

# Specialix IO8+ serial card
ttyW0
ttyW1
#...

# Comtrol VS-1000 serial controller
ttyV0
ttyV1
#...

# ISI serial card
ttyM0
ttyM1
#...

# Technology Concepts serial card
ttyT0
ttyT1
#...

# Specialix RIO serial card
ttySR0
ttySR1
#...ttySR511

# Chase Research AT/PCI-Fast serial card
ttyCH0
ttyCH1
#...ttyCH63

# Moxa Intellio serial card
ttyMX0
ttyMX1
#...ttyMX127

# SmartIO serial card
ttySI0
ttySI1
#...

# USB dongles
ttyUSB0
ttyUSB1
ttyUSB2
#...

# LinkUp Systems L72xx UARTs
ttyLU0
ttyLU1
ttyLU2
ttyLU3

# StrongARM builtin serial ports
ttySA0
ttySA1
ttySA2

# SCI serial port (SuperH) ports and SC26xx serial ports
ttySC0
ttySC1
ttySC2
ttySC3
ttySC4
ttySC5
ttySC6
ttySC7
ttySC8
ttySC9

# ARM "AMBA" serial ports
ttyAM0
ttyAM1
ttyAM2
ttyAM3
ttyAM4
ttyAM5
ttyAM6
ttyAM7
ttyAM8
ttyAM9
ttyAM10
ttyAM11
ttyAM12
ttyAM13
ttyAM14
ttyAM15

# Embedded ARM AMBA PL011 ports (e.g. emulated by QEMU)
ttyAMA0
ttyAMA1
ttyAMA2
ttyAMA3

# DataBooster serial ports
ttyDB0
ttyDB1
ttyDB2
ttyDB3
ttyDB4
ttyDB5
ttyDB6
ttyDB7

# SGI Altix console ports
ttySG0

# Motorola i.MX ports
ttySMX0
ttySMX1
ttySMX2

# Marvell MPSC ports
ttyMM0
ttyMM1

# PPC CPM (SCC or SMC) ports
ttyCPM0
ttyCPM1
ttyCPM2
ttyCPM3
ttyCPM4
ttyCPM5

# Altix serial cards
ttyIOC0
ttyIOC1
#...ttyIOC31

# NEC VR4100 series SIU
ttyVR0

# NEC VR4100 series SSIU
ttyVR1

# Altix ioc4 serial cards
ttyIOC84
ttyIOC85
#...ttyIOC115

# Altix ioc3 serial cards
ttySIOC0
ttySIOC1
#...ttySIOC31

# PPC PSC ports
ttyPSC0
ttyPSC1
ttyPSC2
ttyPSC3
ttyPSC4
ttyPSC5

# ATMEL serial ports
ttyAT0
ttyAT1
#...ttyAT15

# Hilscher netX serial port
ttyNX0
ttyNX1
#...ttyNX15

# Xilinx uartlite - port
ttyUL0
ttyUL1
ttyUL2
ttyUL3

# Xen virtual console - port 0
xvc0

# pmac_zilog - port
ttyPZ0
ttyPZ1
ttyPZ2
ttyPZ3

# TX39/49 serial port
ttyTX0
ttyTX1
ttyTX2
ttyTX3
ttyTX4
ttyTX5
ttyTX6
ttyTX7

# SC26xx serial ports (see SCI serial ports (SuperH))

# MAX3100 serial ports
ttyMAX0
ttyMAX1
ttyMAX2
ttyMAX3

# OMAP serial ports
ttyO0
ttyO1
ttyO2
ttyO3

# User space serial ports
ttyU0
ttyU1

# A2232 serial card
ttyY0
ttyY1

# IBM 3270 terminal Unix tty access
3270/tty1
3270/tty2
#...

# IBM iSeries/pSeries virtual console
hvc0
hvc1
#...
#IBM pSeries console ports
hvsi0
hvsi1
hvsi2

# Equinox SST multi-port serial boards
ttyEQ0
ttyEQ1
#...ttyEQ1027

# ==========================================================
#
# Not in Documentation/Devices.txt
#
# ==========================================================

# Embedded Freescale i.MX ports
ttymxc0
ttymxc1
ttymxc2
ttymxc3
ttymxc4
ttymxc5

# LXC (Linux Containers)
lxc/console
lxc/tty1
lxc/tty2
lxc/tty3
lxc/tty4

# Serial Console for MIPS Swarm
duart0
duart1

# s390 and s390x ports in LPAR mode
ttysclp0

# ODROID XU4 serial console
ttySAC0
ttySAC1
ttySAC2
ttySAC3
9
  • 1
    Might be easier to simply disable the securetty bits in PAM. (see my answer) – Thomas Ward May 14 '20 at 17:56
  • 1
    Yes. Looking at my backups I see that I had exactly the same file previous to upgrade to 20.04. The file info is like this: -rw-r--r-- 1 root root 4141 Jan 25 2018 securetty and its cksum is: 3134771043 4141 securetty. And similarly to you I have the same errors in auth.log – FedonKadifeli May 14 '20 at 17:56
  • Any chance you can do a recursive grep in /etc/pam.d and see where securetty is referenced heynnema? – Thomas Ward May 14 '20 at 18:04
  • 5
    I created a file securetty and copy pasted this into it and restarted the computer. It works. It did not work until restart. So when is the official fix expected to come about? I am brand new to editing Linux kernel files but since it is free I feel like I need to catch up with basics and learn how to fix my own stuff. Can I subscribe to a tracker of this bug somewhere somehow? And why is this question off-topic? Thanks a lot for the answer and sorry about writing my questions here. I don't know any other place to ask these questions. – Arthur Tarasov May 21 '20 at 6:15
  • 1
    I am using a Lenovo X1 Carbon Gen 4 with Xubuntu 20.04 installed. I was having issues waking up after suspend. 1/3 of the time it would freeze on the login screen. Looked in the auth logs and notices that after opening the lid the system could not find the securetty file and would hang. I used the file from 19.10 referenced above and I have not had any issues with logins in three days since adding the file to /etc. – Gopool Nov 1 '20 at 0:37
4

This is not answer. Only an initial attempt to find the correct solution.


The action mentioned at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931899#17 which is to remove secure_nullok [sic] (probably meaning nullok_secure) from the line:

auth    [success=1 default=ignore]  pam_unix.so nullok_secure

at file /etc/pam.d/common-auth seems to work or at least the message is no longer displayed in /var/log/auth.log after this change.

However, looking at a new Ubuntu 20.04 installation I see that this file is similar (with nullok_secure present) and this system too has the same problem of displaying Couldn't open /etc/securetty message. I tested with the login command.

I conclude that this is not an upgrade problem. The problem is present in new installations also.

Please comment...

4
  • 3
    Correct, it's a problem with new installs also. I mentioned that in my question. If I had to guess, I'd say that nullok_secure is to allow null passwords at secure tty's. – heynnema May 14 '20 at 19:18
  • Actually, this "file contains the device names of terminal lines on which root is allowed to login". I think we need to wait for the relevant pam module to be fixed. – FedonKadifeli May 14 '20 at 19:32
  • 1
    The securetty file does that. I was talking about the nulloc_secure parameter. I think that you're right. But in the mean time, dropping in a copy of securetty seems to quiet things down. – heynnema May 14 '20 at 19:36
  • This is in (by which I mean also an issue) the AWS ami for 20.04. – mckenzm Oct 12 '20 at 7:18
-4

The error is correct its not a typo my friend . The issue is ubuntu is gradually shifting towards snap because of which it has implimented the securetty file in /snap/core/9804/etc/securetty rather then usual /etc/securetty . Whereas debian haven't change the kernel code according to that so its just a matter of replacing the locattion of securetty in pam_unit file . I dont know how to do that but if someone knows about that please let us know . I am sure that would solver this bug

1
  • 4
    This error has nothing to do with snap; the path you're referencing has to do with a particular snap's copy of /etc/securetty – Brian Turek Sep 10 '20 at 8:16
-4

A bit like HKCU/System/CurrentControlSet is something like this not the answer to suppressing this error message?

ln -s /snap/core18/current/etc/securetty /etc/securetty
1
  • 2
    No, this is not the correct solution. The file that you found is specific to snaps. – heynnema Jan 7 at 17:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.