Tag Info

New answers tagged

1

Turns out it was a SELinux permissions problem with files in ~/.ssh/. I copied the files from a backup stored on an external drive, where I guess they had received different labels, and they kept their incorrect labels. I should have known. When experiencing puzzling failures that could be permission issues, always check SELinux. The fix: restorecon -r ...


2

I think nlu has pointed into the right direction. The generally better way to trace down ssh problems is by stopping the sshd on the server side and then start it with $(which sshd) -d. That will give you more meaningful error messages in almost all cases. Update: Sorry - you already did this. There seems to be one difference between sshd on the cli and ...


1

You should check the ownership and permissions of /home/user/.ssh/authorized_keys too.


1

You can specify a range with regexes as delimiters with sed. As an example, all entries, that contain anything between 2015:09:56 and 2015:09:6(something): ssh host "sed -n '/2015:09:5[6-9]/,/2015:09:6/ p' /var/log/httpd/access_log" to capture the output in a local file, use redirection, that is: ssh host "sed -n '/2015:09:5[6-9]/,/2015:09:6/ p' ...


0

Your client is not presenting a certificate, because it doesn't have one. You need to generate one (ssh-keygen -s keys/ca.key -I jruser -n jruser keys/client.key.pub). The new certificate (keys/client.key_cert.pub) will automatically be picked up by ssh and presented to the server. Your cert-authority line in authorized_keys lacks the required principals ...


0

If you're running Linux, you can make the warning go away by running this (as root): echo 1 > /proc/sys/net/ipv6/bindv6only What's going on is that ssh is binding a PF_INET6 socket to [::]:5115 before it binds a PF_INET socket to 0.0.0.0:5115. The PF_INET6 socket is bound to both protocols, so the attempt to bind the second socket fails. By turning on ...


1

This isn't actually a UnixWare, Bash or RSH specific problem. It's a quoting problem, and it will affect any system that doesn't have the same date implementation as the remote system. For instance, it will also happen when SSHing from a Mac running Bash to a Linux box. To make the remote system run date instead of the local one, adjust the quoting like so: ...


1

Yea you would be disconnected. Like Celada say "Connecting to the console is the only safe way!". You can try this and if you can't reconnect with ssh, you can go to your console. But if you use the command: ifdown <interface-name> && ifup <interface-name> I think that's gonna be worked (But you gonna be disconnect).


0

Turns out that not only .ssh but $HOME permissions matter! $HOME has to have permissions set no higher than 751.


0

There is really no way for the server to know the difference between a session that was cut off due to a network outage and a session where the user got up and walked away. Some shells may have a timeout feature where, if the shell does not see any activity for a specified amount of time, it will disconnect the session.


0

This allowed me to use my mac over SSH no matter what, as long as the mac is connected to a power source. Everything gets shut down when the mac gets off its power source, so you don't have to worry about battery life.


0

You're running jq on the local machine, since you're using an “unquoted” here document, where the characters \`$ are interpolated. To run the command in the remote shell, arrange for the text passed in the here document to contain the command. Since you don't use any local variable or command substitution, the easiest way to do that is to use a literal here ...


1

Try authenticating with an ssh key. Any program using ssh for the transfer will automatically find the key and not need a password. Simply run ssh-keygen -t rsa -f ~/.ssh/id_rsa Then append your new ~/.ssh/id_rsa.pub onto the remote side's ~/.ssh/authorized_keys file ssh USER@REMOTE_HOST 'cat >> .ssh/authorized_keys' < ~/.ssh/id_rsa.pub and ...


1

Zsh has a preexec hook that executes a function before a command entered on the commandline is executed. Here's a hook that looks for ssh in your command line and if found, checks for the existence of an ssh agent. If that's not found, it runs keychain. So this way, keychain is only run before ssh commands, and then only if needed. Put this in your ...


2

The tool screen is the tool that could help you. It executes a new shell. This new shell is not killed when the terminal is disconnected and it is possible to attach to this shell after reconnection. The usage for keeping session across terminal connections is easy. To start a new session type $ screen Now you can terminate the putty. When you reconnect ...


0

If you really want to prevent local disconnection from putty to prevent your ssh connection from being lost, you can install tmux (or screen) under cygwin and start putty from there. This allows you to disconnect from putty (by disconnecting from tmux) and continue to use the existing ssh connection after reconnecting (to tmux`). This assumes you can start ...


3

First you may check whether ssh-agent is running and start it if not: if ! [ -n "$SSH_AUTH_SOCK" ] || ! { ssh-add -l &>/dev/null; rc=$?; [ "$rc" -eq 0 ] || [ "$rc" -eq 1 ];}; then echo "Starting agent..." eval "$(ssh-agent -s)" fi ssh-add -l exits with code 1 if there are no identities and with code 2 if it cannot connect to ssh-agent. ...


3

The idea of ssh-agent is to have a running service storing all your keys. Therefore you only need to enter your password once and you can even forward your agent to a remote host if you want to log in to a second host from there. First verify that ssh-agent is running using ssh-add -l, which probably says "The agent has no identities." Second you add keys ...


1

You need to make sure your iptables rules allow access to the SSH port. Your router needs to forward from port 7000 to 22 (the default ssh port). In /etc/hosts.allow, add the line: ALL: sshd In /etc/ssh/sshd_config, have the following settings: Port 22 UsePAM yes AllowUsers YOUR_USERNAME_HERE If this does not work, we can try tracing your ...


1

The basic debugging step is to check the trace and the logs. You get a trace of what SSH does by adding the -v option to the ssh command. Repeating the option gives you more logs. Most network- and authentication-related issues require -vv. ssh -vv user@mydomain.com “Connection closed by remote host” is a somewhat generic message: it means that the ...


1

As I remember alias can't use variables inside of it - so use function instead. function sshserv { gnome-terminal --tab --command " bash -c 'ssh root@$1 \"bash -rcfile .my_bashrc\"'" } and use as sshserv server1


1

For zsh, I've written a set of utilities and wrappers to do more or less what you want: https://www.vinc17.net/unix/index.en.html#zsh-ssh-utils Actually this does even more, because the ssh-agent will be shared by all the login sessions (desktop or via SSH, and GNU Screen is supported too if you start login shells from it, e.g. with shell -zsh in the ...


3

I need X installed on the host too, right? You need an X server installed on the host only, and it will need to be running. You will need some X client libraries in the container (installing xbmc will presumably pull these in as dependencies), but not an X server. What exactly are "displays" (like :0 and :1) and do I need to set them? ...


3

I think that the easiest solution is to "see" the local file system (or a part of it) on the server. For instance, you can use SSHFS.


0

I think this is what you want, in your .bashrc or .bash_profile alias cmdname="ssh -t me@intermediary.server.com ssh application.server.com" From man ssh: -t Force pseudo-tty allocation. This can be used to execute arbi- trary screen-based programs on a remote machine, which can be very useful, e.g., when implementing menu ...


2

The root cause of my problem is that the home directory, the .ssh directory, and its child files on the target sever have a wrong permissions. I discovered this issue by looking at messages in log files in /var/log such as secure, and audit/*.


0

If you has access of the ftp of the remote server, we can also use wget to download the files of remote server like below $wget -r --level=9 --no-parent --reject "index.html*" ftp://<USERID>:<PASSWORD>@<MACHINE-NAME>/path/to For more details check the link.


2

This question is a bit old, but I was looking for something similar, and found it here. It creates a second session that shares windows with the first, but has its own view and cursor. tmux new-session -s alice tmux new-session -t alice -s bob If the sharing is happening between two user accounts, you may still have to mess with permissions (which it ...


0

I don't think the -f is actually causing your problem. I don't see anything wrong in your command, given the right circumstances, your command would work just fine. However if there is any stateful middlebox on the path between ssh client and ssh server, then if that middlebox loses state your ssh connection will die or stall. That means you need to take ...


1

ssh HOST_1 "tail -f MY_LOG_FILE" > MY_NAMED_PIPE The tail program is going to buffer its output in blocks of 8 KB or so, because it's not writing to a TTY. If MY_LOG_FILE isn't very active, this may be why you're not seeing any output. Even if it were working, tail isn't writing full lines at a time, so the output from multiple tail instances would be ...


0

You can also use tee with the append option (-a) to merge contents. In terminal #1 ssh HOST_1 "tail -f /path/to/file" | tee -a /path/to/merged/contents In terminal #2 ssh HOST_2 "tail -f /path/to/file" | tee -a /path/to/merged/contents In terminal #3 tail -f /path/to/merged/contents


0

I just did the following: mkfifo MY_PIPE ssh HOST_1 "tail -f /var/log/messages" > MY_PIPE On the local machine I ran: tail -f /var/log/messages > MY_PIPE In another terminal on the local machine: cat < MY_PIPE The output of both remote and local tail -f /var/log/messages commands is visible. The tutorial I followed is from Linux Journal.


0

Had the same problem. In the end it helped either setting type to simple fuse, or (which is more probably) truncating options to: fuse reconnect,idmap=user,allow_other,default_permissions which worked for me in the end


-1

You need to add: PasswordAuthentication no to your sshd_config (that's the server config)


0

Since $DISPLAY is correctly set and the ~/.Xauthority file is not created, this can mean that, though X11 forwarding is taken into account, xauth is not run. One reason could be that it is not in the path (I had this problem under Mac OS X, but this would be strange under Linux). You may want to do the work yourself by creating a ~/.ssh/rc file. For ...


1

gpg-agent and most probably ssh-agent, too, doesn't care what the keys belong to. The keys are identified by their keygrip (the fingerprint of the pure key material whereas e.g. an OpenPGP fingerprint is over the key material and some additional data like the creation date). You can enable / increase the logging in the config file ~/.gnupg/gpg-agent.conf. ...


0

The save solution without root users on the client generate an ssh-key client: ssh-keygen copy it to the server server: mkdir ~/.ssh client: scp ~/.ssh/id_rsa.pub serveruser@server:~/.ssh/authorized_keys allow sudo without password for your user server: visudo serveruser ALL=(ALL) NOPASSWD: /usr/bin/foo /usr/sbin/bar now you can run commands ...


1

Does the command below work? % ssh -o ProxyCommand='ssh -p 2222 userS@SERVER /usr/bin/nc %h %p' userD@DESKTOP If so, you can bake the proxycommand into your ~/.ssh/config to make scp and sshfs calls easier.


1

Not in ssh_config file, but try with ssh-agent command.


1

scp has a -p option: -p Preserves modification times, access times, and modes from the original file. So set your permissions locally and then do the scp. Or, you can use tar: tar -zc file.* | ssh guy@... 'tar -zx -C ~/public_html/kool-stuff; chmod 755 ~/public_html/kool-stuff/file.*' In either case, I doubt execute permissions are ...


1

The command cat /opt/revsw-config/varnish/sites/rijotests4934567_revsw_net.json | egrep 'SERVER_NAME' | cut -b 19-44 is executed locally on your machine, before it is sent over to ssh. This is probably not what you wanted. The "here document" does variable and process substitution so you must escape the backticks to get the desired result.


1

> ssh -v ... gives you output which tells you how authentication was done. This is with public key: [...] debug1: Authentications that can continue: publickey debug1: Next authentication method: publickey debug1: Offering DSA public key: /home/hl/.ssh/id_dsa_srm ...


1

The directory /home/user/.ssh is created automatically when ssh is installed. That is why you get a message saying the folder already exists. To check if the folder is present press Ctrl+h which will show all the hidden files in a file explorer. All the best in you ssh exploration!


0

Another (IMO) easy way would be: # to remote host cat localfile.conf | ssh user@hostname 'cat -> /tmp/file.conf' # from remote host ssh user@hostname 'cat /tmp/remotefile.conf' > /tmp/file.conf Or if you prefer something GUI-like, try Midnight Commander. They call the feature Shell-Link. Most distros have em in their package systems as mc.


0

FYI: 1) The public key is always in the home directory of the user logging in to remote server i.e. if you login as "backup" it is located at /home/backup/.ssh/authorized_keys. User ID when you login defines the public key used at the destination. You can choose the user ID when making connection by two different ways: ssh user_id@destination.server or ...


0

Here's your rules with regard to incoming traffic on port 2222: iptables -A INPUT -i eth0 -p tcp --sport 2222 -m state --state ESTABLISHED -j ACCEPT iptables -A INPUT -i eth0 -p udp --sport 2222 -m state --state ESTABLISHED -j ACCEPT You aren't allowing NEW connections, so you won't be able to connect from outside. This question might now be of ...


0

Your log means that server-side drops the connection. To find out the reason, you should consult server-side logs, they should show reason for disconnection. You should be almost always be able to find logs in /var/log/messages I could guess that, as connection dropped just after client sent version number, server somehow threats client as incompatible.


-2

I was faced with the same problem. I would open ssh session successfully but it would get reset after some time. When i tried to connect gain immediately i would get the error "Connection refused". when i debugged the session i got this message at the time when the connection was getting reset debug1: client_input_channel_req: channel 0 rtype ...


4

The first set of quotes is eaten up by the command line for su, and the second set by the command line for ssh, so that the quoted { print $1} is actually seen as three separate arguments by awk. Escape the quotes (and $, and any other special character you may use): su - admin -c "ssh $i awk -F: \'{ print \$1}\' /etc/passwd" Or: su - admin -c "ssh $i ...


3

It would have been good to tell what SSH server you ask for and what (set of) Unix systems. ! and * are not passwords when you see them in /etc/passwd or /etc/shadow (use getent to read those entries). They are markers that denote whether the account has a password or not and whether it is locked or not. This is an important distinction, depending on the ...



Top 50 recent answers are included