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.