14

I was looking through my sshd_config file and I found this:

#Uselogin no

I know it's commented but there is no explanation above it and when I google it, I get this:

Don't use the traditional login(1) service to log in users. Because we are using privilege separation, as soon as the user logs in the login(1) service is disabled.

OR

Specifies whether login(1) is used for interactive login sessions. The default is "no". Note that login(1) is never used for remote command execution. Note also, that if this is enabled, X11Forwarding will be disabled because login(1) does not know how to handle xauth(1) cookies. If UsePrivilegeSeparation is specified, it will be disabled after authentication.

As far as understand no prevent ssh from using "traditional login" but I can't find anything about "traditional" login.

Could someone explain what it does?

1
  • I migrated an Ubuntu 18.04 -> 20.04 and this line was actually dropped in the sshd_config file during the process. So maybe it's now deprecated?
    – s.k
    Sep 25, 2022 at 10:34

1 Answer 1

21

Ok, we need some history here, back in the days that the primary way to access a UNIX box was a Terminal and a serial line there were four programs involved in logging in. They were init, getty, login, and a shell. init started getty and kept it running. getty opened a serial port (and maybe did modem specific stuff), and then displayed the login prompt and waited for a user name to be entered. When a user name was entered getty ran login with the username and login would then prompt for the password, do account stuff then run the shell, at which point you were able to use the system. This is still used in data centers, virtual machines and many other places.

Next came telnet. Telnet did not use a serial port so things changed a little. init would in addition to getty also start telnetd (or inetd which would start telnetd) telnetd would get the username and then run login and everything would run pretty much the same from there.

Now along comes secure shell. Now secure shell allows you to login without a password (using a key or maybe depending on version GSS) so there were a couple ways to do things, you could do things exactly like telnet and not use the nice features or you can let sshd handle the login and start the shell which allows you to do all sorts of cool things. Unless you have a custom version of login, I recommend that you let sshd handle the logins. (And if you have pam there is not many reasons to make a custom login anymore.)

6
  • 1
    And now the option is gone (at least since Ubuntu 18.04). Jun 19, 2022 at 3:35
  • A true example of generational knowledge sharing... thank you. Jun 19, 2022 at 9:12
  • 1
    @JesseNickles on Ubuntu 18.04, I'm getting a "deprecated" error in the logs when the option is present and when I look at the documentation (man sshd_config), I don't see the option. So I'm thinking it was already removed, but maybe in 20.04 it gave an error instead... Jun 19, 2022 at 14:41
  • 1
    @AlexisWilke Hmm very interesting. I just spun up an 18.04 server and that option exists in sshd_config but it's commented by default. You must be right then, but I don't know why they included the option if it throws a deprecated error! Jun 19, 2022 at 19:00
  • 2
    @JesseNickles, depreciated means that we are about to remove it but it still works. this is done to not break things without warning
    – hildred
    Nov 20, 2022 at 14:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .