i'm doing a dir listing in my .ssh home dir which gives me a strange result:
ls -lsa .ssh/ total 0 ? ?--------- ? ? ? ? ? . · ? ?--------- ? ? ? ? ? .. · ? ?--------- ? ? ? ? ? authorized_keys ·
The weird thing is, that this only happens for one user and only in this specific directory. If I do the ls after a su -l, everything works as expected. Another strange thing is, that my xterm shows the dir listing in a red blinking font! Any ideas what's causing this to happen?
thx!
Edit:
Here is the dir listing as root:
ls -lsa total 52 4 drw------- 2 sdd sdd 4096 Feb 10 15:57 . 4 drwx------ 16 sdd sdd 4096 Feb 10 15:57 .. 4 -rw------- 1 sdd sdd 1628 Feb 10 15:57 authorized_keys
I'm using ext3.
Edit2:
Thx for the answers, but i still get this:
chmod -R 600 /home/sdd/.ssh ls -lsan _ssh.old/ total 0 ? ?--------- ? ? ? ? ? . ? ?--------- ? ? ? ? ? .. ? ?--------- ? ? ? ? ? authorized_keys
This control operator is used to check the status of last executed command. If status shows '0' then command was successfully executed and if shows '1' then command was a failure. The exit code of the previous command is stored in the shell variable $?.
As I understood starting with d is directory and with - (dash) is a normal file.
This letter “t” indicates that a sticky bit has been set for the file or directory in question. Now because the sticky bit is set on the sharedFolder, files/directory could only be deleted by the owners or root user.
The first column above is the file permissions (drwx------ or -rw-r--r--), the second is the owner of the files and directories (jk), and the third column is the group (users). For the file permissions, the first letter is either a "d" or a "-", meaning it's a directory or a file.
That happens when the user can't do a stat() on the files (which requires execute permissions), but can read the directory entries (which requires read access on the directory). So you get a list of files in the directory, but can't get any information on the files because they can't be read. :) If you have a directory which has read permission but not execute, you'll see this. Someone probably tried to protect the .ssh directory incorrectly - it should be "chmod 0700 .ssh/" and owned by the user which owns the homedir. More than likely, someone was following instructions for securing a .ssh file but applied it to a .ssh directory. :)
If you do a chmod 0600 or 0400 on any directory, you can easily reproduce this behavior. Add execute permission to the dir, and it'll work fine.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With