Question sent in by Charles F. from Virginia.

Q: I recently logged into one of my Linux machines as root and have seen the following message:

Last failed login: Fri Aug 20 04:13:45 EDT 2014 from *.*.*.* on ssh:notty

Have I been hacked?  Was is notty?

A:   Notty (or no tty) means that someone has logged in using SFTP or another process which does not require a terminal or tty (TeleTypeWriter).

When a user logs in via SSH typically you are logged in on pts (pseudo terminal slave), which looks like this in a process list:

savona    18848  0.0  0.0  80492  7168 pts/2    S+   10:38   0:00 ssh <host>

If you are logged in at a console, you are logged in on a tty, which looks like this:

savona    4749  4679  1 Mar20 tty2     00:42:51 /usr/bin/gnome-shell

When you log in via SFTP, which does not require a terminal, you are logged in on “notty” or no tty, which looks like this in a process list:

savona  19037  0.0  0.0 131528  4140 ?     S    10:40   0:00 sshd: savona@notty

I hope this puts you at ease, but there are a few considerations you should use when securing SSH connection.

If you see a lot of these failed attempts, it could be an indication that someone is trying to brute force attack your system. You should investigate if you see a high number of these in quick succession.

If you are seeing root@notty, this means root has logged in via a means that does not require a tty (terminal). For security reasons, it is best to deny SSH access to the root user, or any kind of remote access in general.

To configure SSH to deny root login attempts by editing the /etc/ssh/sshd_config and ensure the "PermitRootLogin" is set to no.

PermitRootLogin no

Protections should be taken to secure SSH. Here are a couple example, but not a definitive list.

Use iptables or firewalld to only allow remote connections from trusted IP addresses. This is especially important if your system is accessible from the internet.

Configure SSH to listen on a non-standard port. For example you can configure SSH to listen on port 2222.

Of course there is A LOT more to securing a server and that is beyond the scope of this post. For more information you can read our "Definitive Guide to Securing the SSH Daemon" which goes into much more detail.