Tag Info

Hot answers tagged

23

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


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


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


9

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


9

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.


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.


7

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


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

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


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

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

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


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

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

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


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

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


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

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

Try the Fedora 17 method... systemctl enable sshd.service


4

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


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


4

This is caused by your client rather than the server. The login as: prompt is PuTTY's own, and it won't display the banner before a username is entered. If you're using shared keys, then the banner will be displayed at key exchange time, even if the key goes on to be rejected.


4

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


4

according to this reference, The match patterns may consist of single entries or comma-separated lists and may use the wildcard and negation operators described in the PATTERNS.. Therefore, it should be the same.



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