Tag Info

Hot answers tagged

22

The SSH agent handles signing of authentication data for you. When authenticating to a server, you are required to sign some data using your private key, to prove that you are, well, you. As a security measure most people sensibly protect their private keys with a pass phrase, so any authentication attempt would require you to enter this passphrase. This ...


22

This is not a limitation on the part of your SSH server, this is a limitation on the part of your server's method to encrypt passwords. When encrypting passwords on Unix, the crypt() function is called. This may use one of many backends, a possibility is using DES, or another limiting algorithm (for this particular case, I will assume your server is using ...


20

You probably want to use the ServerAlive settings for this. They do not require any configuration on the server, and can be set on the command line if you wish. ssh -o ServerAliveInterval=5 -o ServerAliveCountMax=1 $HOST This will send a ssh keepalive message every 5 seconds, and if it comes time to send another keepalive, but a response to the last one ...


17

I suspect you're OS is using DES password encryption, which only supports a maximum of 8 characters. http://serverfault.com/questions/361591/ssh-accepts-only-the-half-password From man crypt(3) GNU EXTENSION The glibc2 version of this function has the following additional features. If salt is a character string starting with the ...


7

I found the source of the problem. There was a vague message in /var/log/messages about strange ownership that tipped me off. So I checked, and the permissions of /root, /root/.ssh, and /root/.ssh/* were all correct (700), but the ownership was default.default. I'm not sure how that happened... but I ran: [root@box1:.ssh/$] chown root.root /root ...


7

From the SSH Protocol documentation, regarding channels: All terminal sessions, forwarded connections, etc., are channels. Either side may open a channel. Multiple channels are multiplexed into a single connection. Channels are identified by numbers at each end. The number referring to a channel may be different on each side. Requests to ...


6

I'd highly recommend you use RSA keys rather than passwords for remote SSH logons. Second, you'll want to install Fail2Ban or something similar to discourage brute force breakin attempts (although again, disabling password authentication in favor of RSA public/private key authentication for SSH access would make this a mostly moot point) Third, it's ...


6

The %u client user name is only known if the client side machine is running identd and provides the username on request. tcp wrappers i.e. tcpd does the identd lookup and returns "unknown" if it doesn't get an answer from the client machine. Running identd used to be common practice back in the 90s, but is extremely uncommon these days - and many clients ...


5

I am thinking you problem is not in the port forwarding, but another option in the NAT config in the router. First, ensure if you use your LAN IP, you can successfully SSH from another machine on the network. This ensures SSH works at all. Second, test from another machine outside the network using the public IP. This ensures that port forwarding works. ...


5

A secure default for an OpenSSH installation will have GatewayPorts set to no. This is precisely that restriction. edit See the PermitOpen directive: Specifies the destinations to which TCP port forwarding is permitted. The forwarding specification must be one of the following forms: PermitOpen host:port PermitOpen ...


5

See the AllowUsers and DenyUsers directives of the sshd_config man page (and possibly also AllowGroups and DenyGroups). Basically these directives take a list of user patterns in the user@host format separated by spaces. Directives have the following precedence: DenyUsers, AllowUsers, DenyGroups, and finally AllowGroups. For the simple case of just ...


4

Just upgrading sshd typically won't replace the host key. So yes just upgrade it and it should be fine. Note: You won't typically need this but if you want to be on the safe side you can create a backup of the ssh host keys and copy them back after you upgraded your system. Typically you would have to backup /etc/ssh/ssh_host*. If something went wrong you ...


4

In all honesty, I'd just set up key-based authentication, disable password authentication, and not worry about people rattling the doorknob. Provided you keep your secret key, secret, all will be well. This question comes up a lot, and in many cases it's motivated by concern over clutter in the log files; while it's annoying, it's also a demonstration that ...


4

uther's answer tells you to allocate a terminal but doesn't explain why. The reason is not specific to ssh, it is a matter of signal generation and propagation. I invite you to read What causes various signals to be sent? for more background. On the remote host, there are two relevant processes: an instance of the ssh daemon (sshd), which is relaying the ...


4

If you run a single command (pwd in your case) through ssh, it is not an interactive shell, so the behavior is correct, in my opinion. You should set your PATH in ~/.profile or ~/.bash_profile, not in ~/.bashrc. As found in bash(1) man page: PARAMETERS (...) Special Parameters The shell treats several parameters specially. ...


4

Make sure you keep your SSH server up-to-date. OpenSSH has a good security record, but you don't want to. Consider carefully whether you need to allow password authentication. Normally you should be logging in only from trusted computers (don't type a password on a computer that may be running a key logger), and these trusted computers are generally under ...


4

ECDH/ECDSA keys are preferred when learning a host key for the first time. Since host C already knows host A's RSA key, it keeps using that. But since host C knows nothing about host B's keys, the ECDH/ECDSA is used. (I referenced the release notes for 5.7, when ECDH/ECDSA was introduced). Questions I got: Are both keys needed? Well, yes. Not every ...


4

Within the sshd_config file which is what sets up the sftp facilities you can do the following: AllowGroups sftponly Match Group sftponly ChrootDirectory /webdocs/ABC ForceCommand internal-sftp X11Forwarding no AllowTcpForwarding no PasswordAuthentication yes I do not believe it will do wildcards though. So you'll have to create ...


3

From sshd_config(5) MaxSessions Specifies the maximum number of open sessions permitted per network connection. The default is 10. This man entry for this particular limit is somewhat vague. The change log message adding this feature is a bit more helpful: Added a MaxSessions option to sshd_config(5) to allow ...


3

Without writing a script to parse through /var/log/messages and remove those lines (which is a possibility, you could even run it through cron), you'll be disabling or redirecting all of ssh's output. This isn't the best idea seeing you might get some relevant logs that you'll want to see. What I would do is write something like this: #! /bin/bash sed ...


3

If your connection is refused, and Nmap shows the port to be closed, then you cannot connect. If you have some other way (physical terminal, virtual console, etc) to get access, you can confirm whether the SSH daemon is running with any of these commands (some may not be available on your system): ps -f -C sshd ps aux | grep sshd sudo netstat -ptan | grep ...


3

Look at my question. This is related to yours. So the answer is: Drop the link and look if the process on the server and client side dies. You can also watch your connection with tcpdump -i $INTERFACE port ssh I think it even decodes "ssh-keepalive" if it is active. The default is "not active".


3

How about if you force public key authentication for the specific user, and then restrict his public key with a from= option in the authorized keys file. To force a specific user to use public key authentication: Match User Bad_User PasswordAuthentication no AuthorizedKeysFile /somewhere/the/user/cannot/touch And then in the authorized keys file ...


3

The last (truncated!) line of the error message presumably talks about ownership of /var/empty/sshd, here (Fedora 18) ls -ld gives: drwx--x--x. 2 root root 4096 Feb 8 11:18 /var/empty/sshd/ Running rpm -qf /var/empty/sshd gives: openssh-server-6.1p1-5.fc18.x86_64 So that directory is owned by package openssh-server (perhaps reinstall that one?)


3

By default, the OpenSSH server will look for authorized keys in .ssh/authorized_keys and .ssh/authorized_keys2 unless you set a different value for AuthorizedKeysFile in the configuration file at /etc/ssh/sshd_config. For the rest, I can't see any key file in the directory listing. Have you generated one using the ssh-keygen command?


3

Running SSH on an alternate port doesn't count as security anymore. It only adds a slight bit of obscurity, and an added step of complexity for your users. It adds zero obstacles for people looking to break your network, who are using automated port scanners and don't care what port it's running on. If you want to bolster security on a system that's ...


3

What if you used a tool like autossh to maintain your ssh connections instead? I use autossh to maintain both an smtp (port 25) and imap (port 143) open on my laptop back through a server on the internet with multiple servers behind it that are accessing the internet via NAT. smtp (25) ...


3

As @banjer pointed out in his comment, you're trying the wrong solution for your actual problem. What you need to do is set up fail2ban. It uses iptables in the background to automatically block connection attempts from hosts that generate failed access attempts from various sources. It's incredibly versatile and lets you add and modify different ...


3

Try: $ sudo /etc/init.d/sshd restart systemd If that doesn't work and your using a distro such as Fedora/CentOS/RHEL and it's using systemd then try this: $ systemctl sshd.service reload You can get all the commands that sshd.service will accept by doing this. Hit the Tab key after typing the following: $ systemctl sshd.service cancel ...


3

This is specific to OpenSSH from version 3.9 onwards. For every new connection, sshd will re-execute itself, to ensure that all execute-time randomisations are re-generated for each new connection. In order for sshd to re-execute itself, it needs to know the full path to itself. Here's a quote from the release notes for 3.9: Make sshd(8) re-execute ...



Only top voted, non community-wiki answers of a minimum length are eligible