Tag Info

Hot answers tagged

32

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 ...


27

Ubuntu calls the service ssh, not sshd. service ssh restart The service is also controlled by upstart, and not sysvinit. So you'll find it at /etc/init/ssh.conf instead of /etc/init.d/ssh.


23

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 ...


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 ...


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 ...


15

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 ...


11

Try this command to view the log from systemctl: journalctl -u sshd |tail -100


8

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 ...


8

Try ssh-keyscan domain-name and it'll output the public key for you.


8

The value !root alone doesn't match anything. The value !root,* matches everything except root. The man page is not clear about that but it may be that the order matters i.e. *,!root would be the same like * because the * would match and the rest is not checked any more.


8

Try installing fail2ban from EPEL. It's packaged for CentOS 7 and you'll get updates as they are released. Installing the rpm form another repo may work (it did in this case) but is not the best way of doing things. First of all, install the EPEL repository by issuing the following (as root): yum install epel-release The above should install EPEL and ...


8

Based on @Hauke Laging's comment. When you run strace on the sshd binary it outputs debugging information on how the program starts and what files it tries to access. From which we can use grep to list the /etc/ files which it tries to access. $ sudo strace -e trace=file /usr/sbin/sshd |& grep '^open('|grep '/etc/' open("/etc/ld.so.cache", O_RDONLY) ...


7

As mentioned in the comment, you're using an encrypted home directory, and are likely using pam_mount to mount it. pam_mount mounts the partition using the password acquired during login. Since you're trying to log in via ssh public keys there are 2 issues: There is no password being sent during public key authentication, so it can't mount your home ...


7

You can see which SSH public key was used in the syslog. The authentication subset of the syslog is usually at /var/log/auth.log. For the whole syslog, you can try /var/log/syslog or /var/log/messages. The log lines should look something like this: Sep 10 19:17:00 server.example.com sshd[1337]: Accepted publickey for ansible from 127.0.0.1 port 59934 ...


6

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 ...


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 ...


6

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 ...


5

If you are using PAM for authentication, which is probably the most likely. As root head into /etc/passwd. There you should see your username and path! Change it there and you are home free! EDIT - Sorry it just occurred to me that you maybe didn't want to change your home folder. In that case, simply add: cd /home To the bottom of your .bashrc file!


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

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 ...


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 ...


5

Try the Fedora 17 method... systemctl enable sshd.service This will enable sshd so it starts on the next boot and every subsequent boot, but it won't immediately start up sshd. At this point you can either reboot (which will start it up) or start it manually using systemctl start sshd.service


5

The benefit to ssh-agent is that you only need to enter your passphrase once. If your private RSA key is not encrypted with a passphrase, then ssh-agent is not necessary. The ssh command would be an example of a client.


5

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 ...


5

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 ...


5

Here's an example. Details about how Match works is in sshd_config man page. excerpt Match Introduces a conditional block. If all of the criteria on the Match line are satisfied, the keywords on the following lines override those set in the global section of the config file, until either another Match line or the end of the ...


5

You can run sshd via inetd, with inetd running: sh -c 'your-command; exec sshd -iD' upon an incoming connection (see the caveat in sshd(8) though).


5

I have found the output of sshd and other core services in 'journalctl'. See more at the Arch Wiki entry for systemd: https://wiki.archlinux.org/index.php/systemd#Journal


5

Configuring an SSH server to accept any password would be easy with PAM — put pam_permit on the auth stack, and voilà. The possibility of misconfiguring such an open system is inherent to the flexibility of PAM — since it lets you chain as many tests as you want, the possibility of doing 0 tests is unavoidable (at least without introducing weird exceptions ...



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