Tag Info

Hot answers tagged

22

There are a few ways of fixing this: You can disable host key checking for this particular host. In your ssh_config file (~/.ssh/config), put something like: Host remote.host.name UserKnownHostsFile /dev/null StrictHostkeyChecking no This configures ssh to never store host keys for remote.host.name, but the downside is that now you are open to ...


11

The hostname or IP address is being stored as a hash (or in plain text depending on options and version defaults) in your known_hosts file. The easiest workaround is to add an entry for each host to DNS or /etc/hosts (ugh!) file with the same IP (WAN) address such as in /etc/hosts: your.wan.ip.address servera serverb and then ssh by hostname and ...


8

You don't say which version of Solaris (and, more importantly, SSH) you're using, but sufficiently up-to-date versions of OpenSSH have addressed this problem. Here are two entries from my known_hosts file, which have the same IP address but different port numbers (one is the implicit 22); as you can see the stored keys are not the same. [10.69.55.47]:2222 ...


4

Almost anything puts you at risk. You just need to decide what level of risk is acceptable to you. In this case, the risks of hiring someone are potentially: They might have inflated their credentials and not be as good at the work as they say they are. They might be dishonest and make unauthorized changes to your system. (This is much less common than ...


4

As Kassandry said, you can't do this with a command within the jail itself. What you could do, however, would be to create a separate user (who I will henceforth call closer on the host system. This user should be blocked so that it can only log in with an SSH key. Your jailed user should have the private key and the password for the key. On the host ...


3

Jails specifically forbid the shutdown commands, per the manual page here. Normal machine shutdown commands, such as halt(8), reboot(8), and shutdown(8), cannot be used successfully within the jail. Additionally quoting from The Design and Implementation of the FreeBSD Operating System, Processes running within a jail are not permitted to perform ...


2

You can't use 192.168.0.0 as the IP address on the router / DHCP server. With a /24 subnet (netmask 255.255.255.0) the first usable IP address is 192.168.0.1. For more information as to why see this previous Q&A.


1

I belive it's connected with login_grace_time which means that sshd service will close connection when user is not authed properly in peroid of time given by directive login_grace_time. Since you disabled logging with password user cannot be authed with password so the connection is closed rapidly (which indicates [preauth] part in your log). It's a ...


1

You can add comment at the end of public key in .ssh/authorized_keys. Something like that: ssh-rsa <KEY>.key comment-here It should help you mange this file.


1

Simple and easy. ssh user@servidor "bash -s" < script.sh


1

The UserData from your question is basically a shell script that runs at first boot of your instance. See the documentation on UserData for more details on that. If you want to configure a set of public keys, you can use AWS::CloudFormation::Init instead. In the files section, declare the authorized_keys file: "files" : { ...


1

Just create two sections Match in the config that define required behaviour: Match Address 11.22.33.44/29 AllowUsers * Match Address * AllowUsers


1

To expand on my comment to @larsks answer, I think using ~/.ssh/config entries is much better than modifying /etc/hosts, though I would use the HostKeyAlias rather than splitting out the known hosts to different files. e.g: Host hosta Port 10098 Hostname remote.host.name HostKeyAlias hosta And similarly for hostb



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