i am trying to create a ssh tunnel for executing conky in my contenair.
pc --> server --> contenair(docker)
i can create a tunnel from my pc to the server and from the server to contenair
but i don't know why i can't execute this command from my pc to create a tunnel all the way:
ssh -L 8888:localhost:22 user#62.210.227.219 ssh -t -t -L 8887:localhost:8888 -p 8888 admin#localhost
i get a terminal with nothing. :(
the ssh log from my server
Aug 9 14:57:14 sd-46208 sshd[5867]: Accepted publickey for USER from 82.64.127.210 port 54369 ssh2: RSA 39:50:42:5p:05:0a:7a:f4:66:fb:5d:24:1f:96:09:5f
Aug 9 14:57:14 sd-46208 systemd: Starting Session 1810 of user USER.
Aug 9 14:57:14 sd-46208 systemd: Started Session 1810 of user USER.
Aug 9 14:57:14 sd-46208 systemd: Failed to reset devices.list on /system.slice: Invalid argument
Aug 9 14:57:14 sd-46208 systemd-logind: New session 1810 of user USER.
Aug 9 14:57:14 sd-46208 sshd[5870]: error: Failed to disconnect from controlling tty.
i almost solved my problem
i added in ssh/sshd_config
X11Forwarding yes
X11UseLocalhost yes
X11DisplayOffset 10
AddressFamily inet
and i run
ssh User#60.220.207.219 ssh User#127.0.0.1 -p 9999 i can connect to contenair but i cant execute an application for the moment
Related
I am trying to run an SSH command in a systemd service. Although I the user I set to run the command fedora has permission to everything the command requires (verified by both running the command manually in a logged-in shell without failure and permission checks on the files), it still gives the error of permission denied.
[Unit]
Description=AutoSSH tunnel
After=network.target
[Service]
Type=simple
ExecStart=/usr/bin/ssh -f -TN -L 3333:localhost:3333 -o "ExitOnForwardFailure yes" -o "ServerAliveInterval 60" -i /home/fedora/.ssh/id_rsa ubuntu#server
ExecStop=/usr/bin/pkill -f 3333:localhost:3333
Restart=always
RestartSec=10
User=fedora
Group=fedora
[Install]
WantedBy=multi-user.target
error message:
Oct 16 11:10:47 Lenovoserver systemd[2318595]: autossh-tunnel.service: Failed to execute command: Permission denied
Oct 16 11:10:47 Lenovoserver systemd[2318595]: autossh-tunnel.service: Failed at step EXEC spawning /usr/bin/ssh: Permission denied
Permission checks:
-rwxr-xr-x. 1 root root 808832 Oct 9 2019 /usr/bin/ssh
fedora user has permission to execute /usr/bin/ssh
-rw-------. 1 fedora fedora 2610 Jan 3 2020 /home/fedora/.ssh/id_rsa
fedora user has read access to its private key.
Did I do anything wrong or is this a systemd bug?
It could be SELinux, the new ssh port has to be registered in selinux.
Firs check if the service work by disabling selinux temporarily, if it works add ssh port to selinux as follow.
# Check selinux status
sestatus
# Disable selinux temporarily
setenforce 0
# Check selinux ssh port
semanage port -l | grep ssh
ssh_port_t tcp 22
# Add selinux ssh port
sudo semanage port -a -t ssh_port_t -p tcp 3333
# Check selinux ssh port
semanage port -l | grep ssh
ssh_port_t tcp 22, 3333
Dnsmasq fails to start every time I reboot my VPS. Below is the log about it.
Aug 22 18:14:51 debian dnsmasq[776]: dnsmasq: syntax check OK.
Aug 22 18:14:51 debian dnsmasq[798]: chown: invalid user: ‘dnsmasq:nogroup’
Aug 22 18:14:51 debian systemd[1]: dnsmasq.service: Control process exited, code=exited status=2
Aug 22 18:14:51 debian systemd[1]: Failed to start dnsmasq - A lightweight DHCP and caching DNS server.
Aug 22 18:14:51 debian systemd[1]: dnsmasq.service: Unit entered failed state.
Aug 22 18:14:51 debian systemd[1]: dnsmasq.service: Failed with result 'exit-code'.
I'd set the user and group name correctly in /etc/dnsmasq.conf file. I tried to reinstall dnsmasq and then it worked. But after I reboot the VPS, it failed to start again. Then I have to reinstall again...
So, If I want to use dnsmasq, I have to not to reboot my VPS. But I want to know what causes this and how to fix it once and for all. My VPS's system is Debian 9, kernel is 4.9.0-7-amd64.
Finally, I've found the trouble and fixed it. As the system informed, chown: invalid user: ‘dnsmasq:nogroup’ is the bad code. I thought it should be dnsmasq failed to automatically add user or group that caused the error.
One solution might be manually adding a user named "dnsmasq". I didn't try it but I thought it would work. Another handling way is to looked up user "dnsmasq" in relative files and replace user "dnsmasq" with an existing user like "nobody".
There are 3 places in the /etc/init.d/dnsmasq file that need replace.
if [ ! "$DNSMASQ_USER" ]; then
DNSMASQ_USER="*dnsmasq*"
fi
# /run may be volatile, so we need to ensure that
# /run/dnsmasq exists here as well as in postinst
if [ ! -d /run/dnsmasq ]; then
mkdir /run/dnsmasq || return 2
chown *dnsmasq*:nogroup /run/dnsmasq || return 2
fi
# /run may be volatile, so we need to ensure that
# /run/dnsmasq exists here as well as in postinst
if [ ! -d /run/dnsmasq ]; then
mkdir /run/dnsmasq || return 2
chown *dnsmasq*:nogroup /run/dnsmasq || return 2
fi
Replace 3 empasized places above.
Although I'm not sure why dnsmasq failed to access account files.
I started with cronjobs a while ago, but up until yesterday I've run into a problem I can't figure/find out.
#reboot me /etc/application/start-script.sh
I have Raspbian Jessie (minimal) installed on a Raspberry Pi Zero. One of the users has a cronjob command #reboot. When I check "sudo /etc/init.d/cron status", I can see the cronjob is picked up after a reboot and executed. The only thing is that any output is dropped, the "No MTA installed"-message, (care?).
#!/bin/bash
# My start script
logfile=/home/me/logfile.log
echo "Starting program..." >> $logfile
application
echo "Program started!" >> $logfile
As you can see, it should create a log file, and it does this after a reboot when the script is called as a cronjob. This script works perfectly fine when you manualy execute it, it writes the output to the logfile AND starts the program.
The problem is: the program is not launched when the .sh script is called as a cronjob.
Why is only the application not started when the script is executed???
"sudo /etc/init.d/cron status" output
Mar 17 22:14:45 pizza-pi systemd[1]: Starting Regular background program processing daemon...
Mar 17 22:14:45 pizza-pi systemd[1]: Started Regular background program processing daemon.
Mar 17 22:14:45 pizza-pi cron[292]: (CRON) INFO (pidfile fd = 3)
Mar 17 22:14:45 pizza-pi cron[292]: (CRON) INFO (Running #reboot jobs)
Mar 17 22:14:45 pizza-pi CRON[296]: pam_unix(cron:session): session opened for user me by (uid=0)
Mar 17 22:14:45 pizza-pi CRON[318]: (me) CMD (etc/application/start-script.sh)
Mar 17 22:14:45 pizza-pi CRON[296]: (CRON) info (No MTA installed, discarding output)
Mar 17 22:14:45 pizza-pi pam_unix(cron:session): session closed for user me
Edit the /etc/rc.local file and add the following line in /etc/init.d/cron/start be sure that it should before exit 0.
Follow this link https://rahulmahale.wordpress.com/2014/09/03/solved-running-cron-job-at-reboot-on-raspberry-pi-in-debianwheezy-and-raspbian/
Hope answer is useful for you
There is this strange thing I am seeing.
when ever i try to ssh into a machine with root user, I get logged in as "airoot" but the same does not happen for any other user.
[root#ftc-unem32-22s27 onestopsolution]# ssh root#10.33.22.1
Last login: Tue Jun 3 08:19:17 2014 from 10.32.22.27
[airoot#node0fs ~]#
This happens for root user but for another user say User1234 it doesn't
[root#ftc-unem32-22s27 onestopsolution]# ssh User1234#10.33.22.1
User1234#10.33.22.1's password:
Last login: Tue Jun 3 08:19:09 2014 from 10.32.22.27
[User1234#node0fs ~]$
First, what I'm trying to do is to jail (chroot) the user in a specfic directory for sftp access. I found a great tutorial that made the job, you can find it here : http://www.thegeekstuff.com/2012/03/chroot-sftp-setup/. You should read it first (it's very short) to understand the rest.
With the example in the link, I've no problem to create sftpusers group, guestuser user and lock it to the /sftp/guestuser/incoming directory. Here is how it's done :
groupadd sftpusers
useradd -g sftpusers -d /incoming -s /sbin/nologin guestuser
passwd guestuser
chown guestuser:sftpusers /sftp/guestuser/incoming
service ssh restart
What I've tried to do after is to lock another user (we call it "test") from the same group in /sftp/test. So I've created user like this :
useradd -g sftpusers -d / -s /sbin/nologin test
You see, instead /incoming as directory, I've just put "/", then I've changed rights to /sftp/test and restart ssh. But connection fails and give me this error : Write failed: Broken pipe
I thought it was due to the wrong path "/", so I decided to delete user and re-create it with an /incoming directory :
userdel test
useradd -g sftpusers -d /incoming -s /sbin/nologin test
passwd test
chown test:sftpusers /sftp/test/incoming
service ssh restart
But even after, the test user seems to be compromise for ever, because I have the same error when I try to connect through sftp : Write failed: Broken pipe Couldn't read packet: Connection reset by peer
EDIT :
Here is the log file for sshd :
Jan 24 12:46:20 ns sshd[13786]: error: Could not load host key: /etc/ssh/ssh_host_ecdsa_key
Jan 24 12:46:23 ns sshd[13786]: Accepted password for test from xxx.xxx.xxx.xxx port 37838 ssh2
Jan 24 12:46:23 ns sshd[13786]: pam_unix(sshd:session): session opened for user test by (uid=0)
Jan 24 12:46:24 ns sshd[13949]: fatal: bad ownership or modes for chroot directory "/sftp/test"
Jan 24 12:46:24 ns sshd[13786]: pam_unix(sshd:session): session closed for user test
Jan 24 12:48:17 ns sshd[14103]: error: Could not load host key: /etc/ssh/ssh_host_ecdsa_key
Jan 24 12:48:19 ns sshd[14103]: Invalid user brad from xxx.xxx.xxx.xxx
Jan 24 12:48:19 ns sshd[14103]: input_userauth_request: invalid user brad [preauth]
Jan 24 12:48:19 ns sshd[14103]: pam_unix(sshd:auth): check pass; user unknown
Jan 24 12:48:19 ns sshd[14103]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=xxx.xxx.xxx.xxx
Jan 24 12:48:22 ns sshd[14103]: Failed password for invalid user brad from xxx.xxx.xxx.xxx port 42756 ssh2
Jan 24 12:48:22 ns sshd[14103]: Received disconnect from xxx.xxx.xxx.xxx: 11: Bye Bye [preauth]
Check the debug log for sshd. You'll likely find it complain about the home directory for user test not being secure.
The sshd is very strict about access to the user's credentials in $HOME/.ssh and will disconnect when it cannot access the directory, or when it detects permissions that would allow any other account to access it.
sshd[13949]: fatal: bad ownership or modes for chroot directory "/sftp/test"
Make sure that the owner of the directory is the only account that can modify any file in $HOME and below. Pay attention specifically to the group settings