I want to use cygwin to install sshd in windows. But when I start the sshd service, it says:
The CYGWIN sshd service is starting.
The CYGWIN sshd service could not be started.
The service did not report an error.
More help is available by typing NET HELPMSG 3534.
And the sshd.log says:
Permissions 0660 for '/etc/ssh_host_dsa_key' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: /etc/ssh_host_dsa_key
Could not load host key: /etc/ssh_host_dsa_key
So how to deal with it?
My /var/log/sshd.log had this in the end:
Disabling protocol version 2. Could not load host key
sshd: no hostkeys available -- exiting.
/var/empty must be owned by root and not group or world-writable.
/var/empty must be owned by root and not group or world-writable.
/var/empty must be owned by root and not group or world-writable.
/var/empty must be owned by root and not group or world-writable.
Looking at /var i saw this:
$ ls /var -All
total 0
drwxrwxr-x+ 1 xxxx None 0 Dec 8 15:59 cache
drwxrwxr-x+ 1 cyg_server root 0 Dec 8 16:21 empty
drwxrwxr-x+ 1 xxxx None 0 Dec 8 15:58 lib
drwxrwxrwx+ 1 xxxx None 0 Dec 8 16:27 log
drwxrwxrwx+ 1 xxxx None 0 Dec 8 15:48 run
drwxrwxrwt+ 1 xxxx None 0 Dec 8 15:48 tmp
So i just did chmod 600 /var/empty and that fixed it!
You need to make sure only the cyg_server user can access those keys.
chown cyg_server /etc/ssh*
chmod 600 /etc/ssh*
Those commands do just that, and will allow your sshd to run correctly.
Related
i am currently trying to get wordpress running on Ubuntu Server 18.04 with apache. I managed to get everything to work, but for some reason i am not able to use ls -l properly anymore on the wordpress directories, in which i played around with permissions. The out-of-the-box permissions didn't allow me to update my themes from the wordpress webinterface.
I can't find a solution to this problem, because the permissions are clearly stating, that i have at least read permission.
Problem: ls -l shows question marks and sais permission denied.
Infos: permissions are rwx for owner www-data, rw for group www-data and r for other. Output of groups includes www-data, so the user should be in the www-data group.
Outputs:
$ ls -l /usr/share/wordpress/
ls: cannot access '/usr/share/wordpress/readme.html': Permission denied
...
ls: cannot access '/usr/share/wordpress/wp-comments-post.php': Permission denied
total 0
-????????? ? ? ? ? ? index.php
...
-????????? ? ? ? ? ? xmlrpc.php
$ groups
*censored user* adm cdrom sudo dip www-data plugdev lxd lpadmin
$ sudo ls -l /usr/share/wordpress/
total 172
-rwxrw-r-- 1 www-data www-data 418 Apr 6 2018 index.php
-rwxrw-r-- 1 www-data www-data 7440 Apr 8 2018 readme.html
-rwxrw-r-- 1 www-data www-data 5697 Apr 8 2018 wp-activate.php
drwxrw-r-- 9 www-data www-data 4096 Jul 20 00:53 wp-admin
...
-rwxrw-r-- 1 www-data www-data 3065 Apr 6 2018 xmlrpc.php
P.S.: Any extra tips for wordpress security are useful.
Thanks
edit forgot the permissions of the directory, still confusing.
$ sudo ls -l -a /usr/share/wordpress/
total 180
drwxrw-r-- 5 www-data www-data 4096 Jul 20 17:13 .
drwxr-xr-x 162 root root 4096 Jul 20 02:40 ..
...
set execute bit permissions for group you belong to.
I have folder in /media on ubuntu - shared from windows via fstab and cifs-utils. Can I share this folder to other user: "miki" (not root)
root#localhost:/media#
drwxr-xrwx 4 root root 4096 Nov 15 12:21 .
drwxr-xr-x 23 root root 4096 Nov 14 06:34 ..
drwxr-xr-x 2 padm root 0 Nov 15 09:34 Archive
drwxr-xrwx 2 root root 4096 Feb 25 2019 kekik
I have try with:
root#localhost:~# sudo chmod -R 757 /media/Archive/
but get:
chmod: changing permissions of '/media/Archive/': Permission denied
Find a solution:
need to modify /etc/fstab by changing:
//windowsServer/Archive /media/Archive cifs username=wundowsuser,password=somepass,uid=1000,iocharset=iso8859-1,rw,file_mode=0777,dir_mode=0777,vers=1.0 0 0
and change group of folder (must umont it first!)
sudo umount -l /media/Archive
sudo chown miki:miki /media/Archive/
I'm not using SELinux, and still I can't get the apache user to create files in my cache storage directory. Can this work without using chown to change the user to the actual apache user?
[root#server live_storage]# getenforce
Disabled
[root#server live_storage]# su -s /bin/bash -c 'touch /home/admin/live_storage/c50d02d942c0a3d.cache' apache
touch: cannot touch ‘/home/admin/live_storage/c50d02d942c0a3d.cache’:
Permission denied
[root#server admin]# ls -lsa
total 84
4 drwx------. 10 admin admin 4096 24 mei 10:32 .
4 drwxr-xr-x. 3 root root 4096 9 mei 11:12 ..
4 drwxrwxrwx 3 admin admin 4096 24 mei 10:33 live_storage
[admin#server live_storage]$ touch '/home/admin/live_storage/c50d02d942c0a3d.cache'
[admin#server live_storage]$ ls '/home/admin/live_storage/c50d02d942c0a3d.cache'
/home/admin/live_storage/c50d02d942c0a3d.cache
Figured it out. Apache didn't have execute rights on the /home/admin directory. chmod +x /home/admin fixed the problem
I'm trying to provide my docker container a volume of encrypted file system for internal use.
The idea is that the container will write to the volume as usual, but in fact the host will be encrypting the data before writing it to the filesystem.
I'm trying to use EncFS - it works well on the host, e.g:
encfs /encrypted /visible
I can write files to /visible, and those get encrypted.
However, when trying to run a container with /visible as the volume, e.g.:
docker run -i -t --privileged -v /visible:/myvolume imagename bash
I do get a volume in the container, but it's on the original /encrypted folder, not going through the EncFS. If I unmount the EncFS from /visible, I can see the files written by the container. Needless to say /encrypted is empty.
Is there a way to have docker mount the volume through EncFS, and not write directly to the folder?
In contrast, docker works fine when I use an NFS mount as a volume. It writes to the network device, and not to the local folder on which I mounted the device.
Thanks
I am unable to duplicate your problem locally. If I try to expose an encfs filesystem as a Docker volume, I get an error trying to start the container:
FATA[0003] Error response from daemon: Cannot start container <cid>:
setup mount namespace stat /visible: permission denied
So it's possible you have something different going on. In any case, this is what solved my problem:
By default, FUSE only permits the user who mounted a filesystem to have access to that filesystem. When you are running a Docker container, that container is initially running as root.
You can use the allow_root or allow_other mount options when you mount the FUSE filesystem. For example:
$ encfs -o allow_root /encrypted /other
Here, allow_root will permit the root user to have acces to the mountpoint, while allow_other will permit anyone to have access to the mountpoint (provided that the Unix permissions on the directory allow them access).
If I mounted by encfs filesytem using allow_root, I can then expose that filesystem as a Docker volume and the contents of that filesystem are correctly visible from inside the container.
This is definitely because you started the docker daemon before the host mounted the mountpoint. In this case the inode for the directory name is still pointing at the hosts local disk:
ls -i /mounts/
1048579 s3-data-mnt
then if you mount using a fuse daemon like s3fs:
/usr/local/bin/s3fs -o rw -o allow_other -o iam_role=ecsInstanceRole /mounts/s3-data-mnt
ls -i
1 s3-data-mnt
My guess is that docker does some bootstrap caching of the directory names to inodes (someone who has more knowledge of this than can fill in this blank).
Your comment is correct. If you simply restart docker after the mounting has finished your volume will be correctly shared from host to your containers. (Or you can simply delay starting docker until after all your mounts have finished mounting)
What is interesting (but makes complete since to me now) is that upon exiting the container and un-mounting the mountpoint on the host all of my writes from within the container to the shared volume magically appeared (they were being stored at the inode on the host machines local disk):
[root#host s3-data-mnt]# echo foo > bar
[root#host s3-data-mnt]# ls /mounts/s3-data-mnt
total 6
1 drwxrwxrwx 1 root root 0 Jan 1 1970 .
4 dr-xr-xr-x 28 root root 4096 Sep 16 17:06 ..
1 -rw-r--r-- 1 root root 4 Sep 16 17:11 bar
[root#host s3-data-mnt]# docker run -ti -v /mounts/s3-data-mnt:/s3-data busybox /bin/bash
root#5592454f9f4d:/mounts/s3-data# ls -als
total 8
4 drwxr-xr-x 3 root root 4096 Sep 16 16:05 .
4 drwxr-xr-x 12 root root 4096 Sep 16 16:45 ..
root#5592454f9f4d:/s3-data# echo baz > beef
root#5592454f9f4d:/s3-data# ls -als
total 9
4 drwxr-xr-x 3 root root 4096 Sep 16 16:05 .
4 drwxr-xr-x 12 root root 4096 Sep 16 16:45 ..
1 -rw-r--r-- 1 root root 4 Sep 16 17:11 beef
root#5592454f9f4d:/s3-data# exit
exit
[root#host s3-data-mnt]# ls /mounts/s3-data-mnt
total 6
1 drwxrwxrwx 1 root root 0 Jan 1 1970 .
4 dr-xr-xr-x 28 root root 4096 Sep 16 17:06 ..
1 -rw-r--r-- 1 root root 4 Sep 16 17:11 bar
[root#host /]# umount -l s3-data-mnt
[root#host /]# ls -als
[root#ip-10-0-3-233 /]# ls -als /s3-stn-jira-data-mnt/
total 8
4 drwxr-xr-x 2 root root 4096 Sep 16 17:28 .
4 dr-xr-xr-x 28 root root 4096 Sep 16 17:06 ..
1 -rw-r--r-- 1 root root 4 Sep 16 17:11 bar
You might be able to work around this by wrapping the mount call in nsenter to mount it in the same Linux mount namespace as the docker daemon, eg.
nsenter -t "$PID_OF_DOCKER_DAEMON" encfs ...
The question is whether this approach will survive a daemon restart itself. ;-)
I am configuring hadoop on Ubuntu os. I need to create RSA key pair to allow hadoop to interact with its nodes, so i running this command:
hadoop#ubuntu:~$ ssh-keygen -t rsa -P ""
then I get this:
Generating public/private rsa key pair.
Enter file in which to save the key (/home/hadoop/.ssh/id_rsa):
Could not create directory '/home/hadoop/.ssh': permission denied.
Enter passphrase (empty for no passphrase ):
Enter same passphrase again:
open /home/hadoop/.ssh/id_rsa failed: No such file or directory.
Saving the key failed: /home/hadoop/.ssh/id_rsa.
Forgot to create .ssh dir in your home?
Try that:
mkdir -p ~/.ssh
then re-run ssh-keygen.
Also possibly you doing ssh-keys creation from wrong user.. You started that shell using sudo?
Try to set HOME dir manually or enter right path in prompt.
check your home directory name and permissions
echo $HOME
cd ~ ; ls -l
ls -l .ssh
ls -lR .ssh
if above output is OK and you have correct permissions, perhaps your quota is full
try with "sudo" and see what happens...
Seems like current user doesn't own the contents under home directory.
Gain the ownership as shown as below:
admin#mydb22-02:~$ sudo chown admin.admin /home/admin/
admin#mydb22-02:~$ ls -la
total 32
drwxr-xr-x 2 admin admin 4096 Nov 3 23:29 .
drwxr-xr-x 3 admin admin 4096 Dec 23 2012 ..
-rw------- 1 admin admin 191 Feb 13 2013 .bash_history
-rw-r--r-- 1 admin admin 220 Apr 3 2012 .bash_logout
-rw-r--r-- 1 admin admin 3486 Apr 3 2012 .bashrc
-rw-r--r-- 1 admin admin 675 Apr 3 2012 .profile
-rw-r--r-- 1 admin admin 0 Nov 3 23:29 .sudo_as_admin_successful
-rw------- 1 admin admin 4221 Nov 3 20:31 .viminfo
generating keys would work now as .ssh directory will now be created and owned by current user after generating the assymetric keys
I have spent arround 1 hr on this and finally got the solution. It is due to permission problem. You have to use chown for your 'hadoop user'.
1. First make hadoop directory.
cd /home
mkdir hadoop
then check 'ls -l'. it gives result like :
drwxr-xr-x 2 hadoop hadoop 4096 Aug 22 22:17 hadoop
2. sudo chown hadoop.hadoop /home/hadoop/
3. Then run remaining command for key generater.