Tag Info

New answers tagged

-1

First, figure out what went wrong tail -f /var/log/auth.log Then vim /etc/passwd


1

similar question here permission denied for root@localhost for ssh connection answer was By default, the SSH server denies password-based login for root. In /etc/ssh/sshd_config, change: PermitRootLogin without-password to PermitRootLogin yes And restart SSH: sudo service ssh restart


0

I solved this problem the "old fashioned way": I put a terminal on the server. But I just tried using the XTerminal remotely again and it connected. So we'll chalk this up to "just one of those things." Thank you to everyone who replied.


0

I did usual update of Ubuntu 14.04 today. After this I had always to enter passphrase when using ssh. Adding eval `gnome-keyring-daemon --start` to the bottom of ~/.bashrc helped me.


0

Packages you are trying to install (i.e chkconfig and sysv-rc-conf ) are in Universe Repository ( chkconfig, sysv-rc-conf ). So you have to enable the Universe Repository so that you install software from it. To enable it Open Software Sources Under Ubunut software tab ,check the option "Community-maintained free and open-source software (universe). ...


0

As you can see here http://packages.ubuntu.com/lucid/sysv-rc-conf that package is in the universe repository. Make sure you have a line in your /etc/apt/sources.list that looks like this: deb http://en.archive.ubuntu.com/ubuntu/ lucid universe Then run apt-get update to update your package list. The package should then be installable.


0

I just use sudo -i to log in as root on a local machine's terminal.


0

For Ubuntu 14.04 LTS The nautilus window has slightly changed. Pre-requisites: Log in to the server. Add your public key to ~/.ssh/authorized_keys Open nautilus on your local computer. Log in using this URL format: ssh://user@server. To cd to anything other than your home patch, append with a slash. ssh://user@server/var/www for example.


0

So, the issue was my router (it is a really bad router; WRT120N). I've had various other issues with it in the past. After restarting it, the problem was gone.


1

I have no problems using Host aliases defined in .ssh/config with rsync. Perhaps you shouldn't be using the sudo, which might make SSH use root's settings.


0

/etc/init/ssh.override is the one where default ssh options are overridden. cat /etc/init/ssh.override manual exec /usr/sbin/sshd -D -o PasswordAuthentication=no So you can remove it from here.


1

Make sure in your /etc/ssh/sshd_config you have the following settings: PubkeyAuthentication yes ChallengeResponseAuthentication no UsePAM yes AllowUsers YOUR_USER_NAME


0

Perhaps this will work: sudo iptables -A INPUT -p tcp --dport ssh -j ACCEPT


0

My current solution is: find out the IP schema for internal IPs (in my case: 10.115.x.x) and create corresponding rule in the ssh config: Host 10.115.* ProxyCommand ssh forward@my_gateway_machine nc -q0 %h %p


0

Check the permissions and ownership of the file /home/hduser/.ssh/authorized_keys It should be -rw------- hduser hduser If not, you can fix this with chown hduser:hduser ~hduser/.ssh/authorized_keys chmod 0600 ~hduser/.ssh/authorized_keys Then try to connect to your localhost with ssh -i /home/hduser/.ssh/id_rsa hduser@localhost If it still doesn't ...


0

Do you have any tcpwrappers ? Start the logging in the server : tail -f /var/log/auth.log Try to ssh from the client and paste the error logs. I think ssh known_hosts is causing the issue. Just backup and clear the known_host file and try again


0

sudo service ssh restart will not do it. You need to restart sshd, not ssh: sudo service sshd restart


0

Background information Ubuntu changed to Upstart as the init system, from System-V. It's a lot faster, by enabling parallel starting/stopping services, decreasing boot times significantly. Services are depending on each other sometimes, for which System-V had a fixed order of starting/stopping them for each runlevel. For Upstart, the dependencies are ...


0

No, you decided what operating system to use when you signed up with them. If you picked Windows, Fedora or CentOS you wont be using Ubuntu. If you chose Ubuntu it will be the version they installed for you. This only applies to dedicated servers. If you have a managed Virtual Private Server Ubuntu is not even an option.


1

As per Tamil Selvan's comment, restarting does indeed fix this on *buntu, with a fresh install of Teamviewer. I had the same issue with an AWS EC2 instance.


0

Let me try an answer then since I think we are getting there: a) Remove the port forwarding and the static IP for your pi first, i.e. let everything go its default way and make sure that the pi can then ping outwards. b) See what the pi has as its ip address, most likely 192.168.x.y, depending on how your hub is set up. c) Try to assign exactly this ...


0

I think this should work: ssh://abcd:1234/home/myfolder You will be asked for a username and a password.


0

Try using the IP or URL of the server, preceded by ssh like this: ssh://(ip address) or ssh://URL See the example: As you see, you can use other prefix like smb (samba) sftp (FTP over SSH), dav for webdav or davs for webdav over SSL.


0

You can terminate the running process ps -ef | egrep '(ssh|PID)' You will get one /usr/sbin/sshd with PID and UID root. This is the listening daemon. All other sshd : user@pts/0 records are user sessions. Look for appropriate session by username and kill the process to terminate this session. Once it is done you can start the ssh process


2

This could be done using a PolKit policy, if you have admin privileges. Create a .pkla file in /etc/polkit-1/localauthority/50-local.d (say disable-shutdown.pkla), containing: [Disable Shutdown, etc.] Identity=unix-user:* ...


0

Please try to check whether the MAAS has been taken out of both the machines using the command ~/.juju/environments/maas.jenv After doing the above try to use the SSH. It helps to connect.


0

Password auth is disabled on the SSH server by default. You first have to enable it. See: https://help.ubuntu.com/community/SSH/OpenSSH/Configuring If the problem continue to exist, examine the sshd log file first. Also note that you have to provide your login name, not the server name: ssh -v -Y username@192.168.56.1


1

It is safe to continue, this is opening a second SSH daemon on port 1022 in case SSH fails/crashes during the upgrade you have the ability to ssh in to port 1022 if need be to repair. (The likelihood of something failing w/ssh is very very low)


1

For KDE: look if gnome-keyring-daemon is running on your system. Then find out, with which application it came to your system (probably gnome libs you needed to run some gnome applications). I had the same problem. I've killed the gnome-keyring-daemon and tried another ssh connection and no extra window showed up and I was asked to enter my passphrase for ...


1

Heartbleed only affects SSL/TLS connections, not every crypto function in the OpenSSL library, and sshd doesn't use SSL/TLS at all, so it's not affected by Heartbleed even if it's compiled using affected OpenSSL versions. See this question and answer.


0

The SSH daemon on the phone runs with the options /usr/sbin/sshd -D -o PasswordAuthentication=no which overrides any options in configuration files. It might be difficult to change that. In this case it might be easier (and more secure) to set up public key authentication. Paste your public key to /home/phablet/.ssh/authorized_keys2. Yes, there is a 2 at ...


1

This cannot be solved through SSH. Go to the console, boot your iso, change into your home folder, find thumbnails, internet caches and delete them all. Disable your internet connection because Ubuntu or other programs might fill the the available space with security updates, ... and run out of disk space immediately. Try to reboot (still offline) and run ...


0

No such file or directoryart.sh Since the script you're trying to call is start.sh, you have a typo somewhere


-1

As I can see you don't delimit your commands. You should delimit your commands with semicolon (;) or double ampersand (&&). The difference between the two is that when you delimit your commands with &&, then the next command only run if previous succeed, while ; delimited commands run anyway. So, you probably should write something like ...


-1

If you have changed/replaced your system hard drive incase then try removing the hostkey from .ssh/known_hosts file then try connecting again.


0

Add the ssh 192.168.xx.xx subnet 255.255.xxx.xxx to the host.allow file


1

Yes, but not on a FAT filesystem. ssh will only use private keys with permissions set to 400 or 600, but FAT doesn't truly allow for this. To get around this, I made several partitions on my USB key. This gives me a Linux partition for my OpenSSH keys, and a FAT partition for my PuTTY keys. I can then use ssh-add/pageant to load the appropriate key, and ...


1

The error message you get does not mean you cannot run two ssh clients at the same time. Rather what it means is that one of the two IP addresses you connect to is not running an ssh server. If you were to start the two ssh clients in opposite order, you could expect the first to fail and the second to succeed. If both IP addresses happen to be assigned to ...


2

Use ~/.ssh/config: Add a host: Host y HostName domain.com Port 666 User username IdentityFile ~/.ssh/id_rsa-domain And then access your host from a terminal: ssh y Also, you can create a shortcut to your terminal that opens a ssh session right away. Save this to a y.desktop file and place it in your ~/Desktop folder: [Desktop Entry] ...


0

Try the below command and check whether you are able to configure samba, sudo apt-get install system-config-samba


0

Found the answer here: https://unix.stackexchange.com/questions/37164/ssh-and-home-directory-permissions Turns out, /home/surfrock66 can't be 777 (which it shouldn't have been anyway). It is now 750, and it works perfectly.


0

On my system I had to open up ports using gufw (gui for uncomplicated fire wall) also if your trying to access the host fron a non-local network you will also need to set up your LAN's firewall to allow and direct traffic to the specific machine and port. On a side note if your planning on open your LAN to the outside world don't use port 22, as this is the ...


1

I always end up sudo apt-get remove --purge gnome-keyring anyway, followed with a restart. ubuntu-sso depends on it but I don't use that, so no worries. ssh-agent seems to just work as it should afterwards.



Top 50 recent answers are included